I don't know what software you were using, but it doesn't sound like Nix.
1) Your scripts should be part of a package. I don't know about Nix, but in Guix we have a build step that patches shebangs to remove the nasty /usr/bin things and replace them with references to the right executables in the store.
2) You can copy the closure of a build, that is the build your are interested plus all of its recursive dependencies, to another machine and it will work just fine. In fact, this feature is a big part of how we produce the Guix binary tarball. Yes, the output of a build is a function of the version of Nix/Guix used to build it, but that has no bearing on whether or not you can run the resulting binaries on another machine.
3) Given that problems 1 and 2 are invalid, I don't know what else to say to this.
Docker and Rocket do nothing to solve the problems that Guix and Nix solve. Container images are not reproducible. You and I can build an image from the same Dockerfile and I guarantee that the checksums would be different. Reproducibility is being able to build the same thing N times on M different machines and get the same exact result, bit for bit. Guix and Nix are getting us to this goal, Docker and Rocket do nothing. Also, you cannot "rip your system in half" with Nix or Guix. They provide roll back facilities to undo bad changes to user profiles or the system configuration.
> I don't know what software you were using, but it doesn't sound like Nix.
I love how the initial reaction by every Nix user is to imply I'm a liar or just titanically stupid. Like it's not possible that a relatively new linux distribution that has just undergone a major overhaul of its package management system might still have bugs or issues.
No. NixOS is perfect for everyone today. Just completely rewrite every deploy script you have from the ground up. Having trouble? Don't worry! The documentation is "getting better."
> Your scripts should be part of a package. I don't know about Nix, but in Guix we have a build step that patches shebangs to remove the nasty /usr/bin things and replace them with references to the right executables in the store.
Sorry, but I will not be writing an OS-integration package for every specific software deploy during development. It's unlikely to even imply that I should be doing this during development just to get off the ground. I tried to use NixOS as an environment for development for Golang and Java and found it frustratingly at odds with all existing tooling. The only languages I found that seemed well supported was haskell and C, and I don't ship code on either of those platforms anymore.
It was doubly unlikely early this year. The documentation was in utter disrepair and more than two Nix developers told me on twitter, "It is very difficult to do unless you are a contributor." It was also the case that many pre-existing packages were done incorrectly, still suffering these problems. Golang's package was one of them.
> but that has no bearing on whether or not you can run the resulting binaries on another machine.
Copying a closure to deploy software projects currently in development is an extremely intensive step, and many packages had outstanding bugs that don't do this.
Furthermore, existing deploy tools like Puppet, Salt and Ansible all have extreme difficulties managing this model, but Nix (at least at the time I examined it) didn't offer very good tools for actually distributing said closures in a cloud services environment.
> Container images are not reproducible. You and I can build an image from the same Dockerfile and I guarantee that the checksums would be different.
It's not the responsibility of the dockerfile to maintain this immutability. It's the responsibility of the environment the dockerfile is executed in.
Which is probably why Golang was specifically such a problem, it has a really miserable story for actually making reproducible builds with locked deps.
Given a specific git SHA for a project with locked dependencies, it is absolutely reproducible and will produce the same image SHAs every time.
P.S., at the time NixOS was going through a major update and it was possible to install a version of Nix onto NixOS that was not entirely compatible. This ruined the install while still using Nix commands. If that bug has been fixed, great, but it was a known issue and I was not the only person in IRC asking for help with it. You lost your ability to roll back.
1) Your scripts should be part of a package. I don't know about Nix, but in Guix we have a build step that patches shebangs to remove the nasty /usr/bin things and replace them with references to the right executables in the store.
2) You can copy the closure of a build, that is the build your are interested plus all of its recursive dependencies, to another machine and it will work just fine. In fact, this feature is a big part of how we produce the Guix binary tarball. Yes, the output of a build is a function of the version of Nix/Guix used to build it, but that has no bearing on whether or not you can run the resulting binaries on another machine.
3) Given that problems 1 and 2 are invalid, I don't know what else to say to this.
Docker and Rocket do nothing to solve the problems that Guix and Nix solve. Container images are not reproducible. You and I can build an image from the same Dockerfile and I guarantee that the checksums would be different. Reproducibility is being able to build the same thing N times on M different machines and get the same exact result, bit for bit. Guix and Nix are getting us to this goal, Docker and Rocket do nothing. Also, you cannot "rip your system in half" with Nix or Guix. They provide roll back facilities to undo bad changes to user profiles or the system configuration.