-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
+= Dockerfile and updated README.md #115
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @gww-fuel thanks for the PR! Sorry I haven't been able to come to this repo for some time. Generally using nix would mean you don't have to deal with docker files since it will generate you the build environment you need. I guess this is for getting nix itself which makes sense. So given that nix flake itself is self sufficient in building stuff, we can get away with only installing nix and calling the flake which is what you did in this PR so we can merge this.
There are things that we can improve (for example nix flake itself can accept different suffixes for different derivations, this can be enabled through the docker file itself too) but, for nix user a docker file would be irrelevant so this is more towards non-nix users to quickly spin up something, so I think it makes sense to keep this as it is, (only getting the default derivation from the flake etc) cc @JoshuaBatty
utACK, I will be testing it locally in couple of hours as well.
Thank you for change and feedback! I am new to Nix,and happy to get better at this. I consider two topics orthogonal:
One takes care to configure things, However if Nix allows for network namespace, process namespace, syscalls and other dimensions of isolation I would love to learn about it! (
Probably it is topic for dedicated ticket to offer users script that has all docker flags configured to run fuel.nix with absolute minimum permissions required To sum it up, here the use of docker is to provide maximum usability for users for deployments (as dockers are widely supporter), and even more, to provide convenient way to enable different levels of isolation mechanisms for enhanced security. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I haven't had time to properly think about this. Just requesting changes to pause this getting merged before I come back to this early next week.
To learn more: https://docs.docker.com/build/cache/ .
Sorry this has taken me so long to reply to. While I can sympathise with why using docker in this circumstance could be useful to a certain type of developer, I am weary about including this information in the documentation for this repo. The target audience for this repo specifically is existing nix users who are already using it to manage system dependancies. As such, I'd prefer if our documentation didn't splinter into trying to be more than this. I'm still open to the idea of having this information hosted somewhere, but I think that needs to be part of a larger decision. |
Sure! What about keeping in sub-directory Also for people who isolate their build environments or like to make CI/CD pipelines, do we want them to not use fuel.nix and use only https://github.com/FuelLabs/fuelup directly ? Of course we can have separate repo https://github.com/FuelLabs/Dockerfiles , if that's what you had in mind. It's just against common practice. Its like someone making separate repository https://github.com/FuelLabs/Makefiles for So, should I go ahead and undo changes to I have to admit that without Dockerfile in this repository, and zero Nix experience, it took me time to make one that would work, and thought that making it easy for other enthusiasts who would like to embrace and play with Nix and experiment is inviting and helpful. |
Hi @gww-fuel sorry for the late reply.
Yes I think that makes the most sense. I think this PR makes more sense against the |
Thank you for taking a look! One of reasons how this PR originated, was confusion if fuel.nix and fuelup are considered with same focus two possible toolchain managers, and two different for e.g. failover of alternative implementation. Given answer it sounds like fuelup is considered to be main focus, and fuel.nix only for nix users, therefore makes total sense to make Dockerfile against fuelup to incentivise wider use and focus on main toolchain manager. |
I am Nix/NixOS newbie, I hope this PR will be inspiration for someone to make nice Docker to build everything inside (i.e. not requiring any tools on host, e.g. hix) or eventually opportunity for me to learn through code review process. Or maybe that's good enough Dockerfile to start with 🤞 .
Try: