I was wondering as to what the hell must the motivation have been for shifting from the widespread, easy to understand and reason for, easily maintainable, widely popular DOCKERFILES to this esoteric package manager that they call ‘nix’! What’s so “nixy” about it? I can’t think of anything that nix does that docker can’t. Even if rolling out updates would have meant publishing a new image and informing the community of the updated ‘latest’, so what? Any of its drawbacks were not significant enough to warrant trading away a-prior familiarity of the technology stack by mainstream developers (docker being the state-of-art in the town). God knows what else the “experts” have in mind… Anyway, just a thought…
2 Likes
In response to the increased interest on the subject, I’d like to add that the future is bright, folks, as God has already sent a prophecy (I mean, David, our Holochain God, has already hinted the possibility for a bright future; haha):
Responding to:
Meanwhile, the price of setting up nix (and all that) continues to be well worth the effort.
docker and nix solve different problems and are not mutually exclusive or directly comparable
docker manages virtual environments, it is an alternative to e.g. vagrant, virtualbox, dual booting
nix builds and manages dependencies within an environment, it is an alternative to e.g. ansible, npm, apt-get, bash scripts
i.e. nix is the command you put after RUN in the dockerfile not the dockerfile itself
we could debate nix-shell vs. chocolatey or apt-get or homebrew or npm or curl | sh or make whatever… but that’s a different conversation
i used to maintain docker boxes and install scripts without nix and they were relatively fragile and unpopular, i got sick of fixing something that only a handful of people used so i stopped
my experience is that there is no ‘standard way of working’, e.g. people:
- happily familiarise themselves with nix or
- prefer to completely manage their development environment themselves or
- prefer virtualisation solutions to give a ‘black box’ experience or
- something else, e.g. a corporate mandated system
many people cannot or don’t want to work with docker
the basic strategy to satisfy as many people as possible:
- start with a baseline of minimal dependencies
- e.g. stick with everything as stable rust, not ‘polyglot’
- e.g. prefer rust crates over binary dependencies
- define those dependencies explicitly in nix
- they can be used directly or referenced by the manual crowd
- wrap nix in docker/vagrant for people who like the virtualisation ‘black box’
- work towards native support from the binary for as many platforms as possible without any additional dependencies or wrappers
it is better to ‘dockerise’ an increasingly portable baseline than it is to ‘undockerise’ an increasingly specialised black box
in the meantime you should make a dockerfile for your project if you like to work that way, there’s no reason to wait on me for that
the minimal dependencies for rsm are:
- stable rust
- with wasm target installed
- maybe libsodium
it should be possible to cargo install holochain inside the dockerfile
1 Like
Exactly what I was asking for when I first created this discussion… Was going to dockerize it myself after getting the whole thing running in WSL first. However, by now I’ve got so used to the present setup that docker does seem like another “black-box” layer on top of everything (i.e., not so worthwhile, though I wouldn’t mind if someone else does it; ¯\_(ツ)_/¯ )…
Anyways, upon cloning a new commit, just to be safe, I do:
nix-collect-garbage -d
and then freshly install the new one from scratch. But it’s a bit time-consuming and boring… So my question is that is it something that everybody does, or is it just me? (Do you just checkout the new revision in the same old Holochain workspace, or does the new happDev nix-flavor does it all for you, or something else? There’s no documentation on how to keep moving ahead with newer commits on the repository… Would love to know the professional way of keeping the setup up-to-date… )
nix hashes every build so it keeps itself up to date, no need to do anything else
generally the branches of the holonix repository reflect various states of stability
nix-collect-garbage is more like dropping the old cached dependencies if you find it takes up too much space on your machine
cc: @stev
1 Like