Hacker News Reader

Comment by jonhohle | Hacker News Reader

Missing: all of the other software on the host (including maven) and the OS itself.

Yes, maybe it doesn't apply to Java but I've been unable to setup projects on a new machine because library versions changed, external programs became hard to build themselves, some sw is impossible to find anymore (I remember a customer with a prehistoric MySQL, we had to find the oldest available bug compatible version and hope - they had no tests), etc.

A Vagrantfile or a Dockerfile are not enough. You need the actual images.

Or in your docker file you specify versions of things to install, check in repos to use, etc etc.

It's versions all the way down

You're assuming that all those repos are still around 5 years later.

Definitely true.

Not sure I am a fan of having every git repo having a copy of everything over and over and over, for "ecological" reasons... But it's probably the best way to endure that your builds will work.

They are if you mirror the Docker registry. We use Sonatype Nexus and get the added benefit of having our own private Docker, NPM, Maven, etc. repositories on top of automatically caching dependencies we use.

So now we don’t have to worry about them disappearing AND we don’t have to leave the network to get them... assuming we don’t screw up our server.

We own our registry. That's why we have the images for one project. We install from there.

What we don't do yet is storing a pristine a VirtualBox image for another project. We should start doing that because sometimes building those images requires a surprising amount of work. Bitrot, etc.

So this is why I create Nix files for all of my projects and do all builds from within a nix-shell.

You then get to decide to what extent you want to freeze your exact dependencies or leave them abstract to some degree.

And do you freeze the nixpkgs version as well?

Again, depends. It's a tradeoff. As much as you want reproducibility, you never really want to be wed to security bugs.

I tend not to but generally consider myself on the fence about that one.

I hard-code ("freeze") known-good versions of dependencies (including nixpkgs) in my derivations; but I also check to see if an override has been given in NIX_PATH (using `builtins.tryEval <foo>`).

This way, I can override things if needed; and in particular I have continuous integration (Hydra) building both a "stable" (all fixed versions) and "unstable" (all latest versions).

This way I always have a known-good build I can use, but I can still spot impending breakages and bit-rot in CI.

In the case of nixpkgs I don't actually track the very latest commit, since it updates so often. Instead I just `git pull` into a fork every now and again.

It recommends using the Maven wrapper to fix Maven's version.

Reply on news.ycombinator.com