4 ms·

First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to

by Arkh4m 5y ago

First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to reload your shell. Most current version managers either do it themselves through shell hooks or ask you to install direnv. Point taken on using brew: I've changed it to use nix-env. Third. Yep. Sort of like having to learn English before you can learn programming. Fourth. As they say: start with the basics. Fifth. No other package manager can freeze the complete dependency set you are using AND allow you to revert it exactly when things don't work. That's the power of declarative, reproducible builds: you try to update and it doesn't work? No problem, revert to the last working version and things are all good again. Sixth. Ever tried updating a project using a Dockerfile that uses an old version of ubuntu? Then you can't find the packages anymore or no is building them anymore for the new version of Ubuntu and you have to pull random PPAs from the Internet to get things to work? In Nix, you can keep two pinned nixpkgs versions at the same time. In this way you can keep working on upgrading your project one working step at the time. So yeah, it's not just cHeCKmATe FP-atheists sort of stuff.

throwaway984393 5y ago
For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them after they're built the first time in an artifact repository. Any builds of your app that use a container need to be versioned to prove they've been tested successfully, anyway, and you want to keep them around to do fast rollbacks without having to kick off a build just to roll back. So you don't need reproducibility for reliability. It's mostly used for security: build on two siloed systems, compare the results. Version-pinning in general is to prevent silent upgrades that break your builds. But you also don't want to version-pin everything, as you want security patches to get automatically applied with regularly-recurring builds. So in practice, you stick with a major branch of something, silently accept upgraded packages or minor version bumps, and have an automated system flag if you aren't running the latest security packages. All of that works fine with Docker and Apt. More often than breakage due to silent upgrade is the security patch problem, where somebody pinned to a version 4 years ago and has never patched, and it's been so long that all the downstream effects of patching force you to do an entire lift-and-shift to new everything. Gradual continuous updates (stick to a major version, run tests) is the best middle ground. Modern projects with Docker containers have standardized their tagging around this.
dmitriid 5y ago
> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution" for that is to dig through some commit hashes, and use those. Commit hashes are not versions. 2. Your example points to a completely random version of a package The previous issue already points to a random version, apparently, but this is further compounded by the fact that "ruby_2_6" and "nodejs-10_x" point to a random version that is available at the time. To truly make the claim that nix allows reproducible builds, it needs to provide: - a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is - a way to actually properly pin package versions. Something that all package/dependency managers allow you to. If I want to pin ruby to exactly 2.6.7, for an actual reproducible build, what is nix' solution for that?
- ducktective 5y ago
  You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
  - dmitriid 5y ago
    > You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes 1. How? You'd think such a simple thing, especially in the context of "ditch version managers" would be easy and warrant at least an example. So far I've had: - ignoring the question or avoiding the answer - one answer "just use overlays" with no example - one answer "just use flakes" with no example 2. It's a separate, unstable feature It amazes me that after 18 years, you still need (probably? no idea) to use some entirely separate feature that is still unstable/experimental and uses an entirely different system of describing what's needed than nix proper. And still no answer how to do the thing that is literally required for every single reproducible build: pin a tool to a specific version. Meanwhile tools that we're supposed to ditch are as simple as rvm install 2.1.1 rvm use 2.1.1

by Arkh4m 5y ago

throwaway984393 5y ago

For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them after they're built the first time in an artifact repository. Any builds of your app that use a container need to be versioned to prove they've been tested successfully, anyway, and you want to keep them around to do fast rollbacks without having to kick off a build just to roll back. So you don't need reproducibility for reliability. It's mostly used for security: build on two siloed systems, compare the results. Version-pinning in general is to prevent silent upgrades that break your builds. But you also don't want to version-pin everything, as you want security patches to get automatically applied with regularly-recurring builds. So in practice, you stick with a major branch of something, silently accept upgraded packages or minor version bumps, and have an automated system flag if you aren't running the latest security packages. All of that works fine with Docker and Apt. More often than breakage due to silent upgrade is the security patch problem, where somebody pinned to a version 4 years ago and has never patched, and it's been so long that all the downstream effects of patching force you to do an entire lift-and-shift to new everything. Gradual continuous updates (stick to a major version, run tests) is the best middle ground. Modern projects with Docker containers have standardized their tagging around this.

dmitriid 5y ago

> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution" for that is to dig through some commit hashes, and use those. Commit hashes are not versions. 2. Your example points to a completely random version of a package The previous issue already points to a random version, apparently, but this is further compounded by the fact that "ruby_2_6" and "nodejs-10_x" point to a random version that is available at the time. To truly make the claim that nix allows reproducible builds, it needs to provide: - a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is - a way to actually properly pin package versions. Something that all package/dependency managers allow you to. If I want to pin ruby to exactly 2.6.7, for an actual reproducible build, what is nix' solution for that?

ducktective 5y ago
You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
- dmitriid 5y ago
  > You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes 1. How? You'd think such a simple thing, especially in the context of "ditch version managers" would be easy and warrant at least an example. So far I've had: - ignoring the question or avoiding the answer - one answer "just use overlays" with no example - one answer "just use flakes" with no example 2. It's a separate, unstable feature It amazes me that after 18 years, you still need (probably? no idea) to use some entirely separate feature that is still unstable/experimental and uses an entirely different system of describing what's needed than nix proper. And still no answer how to do the thing that is literally required for every single reproducible build: pin a tool to a specific version. Meanwhile tools that we're supposed to ditch are as simple as rvm install 2.1.1 rvm use 2.1.1