Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ditch your version manager

juliu.is

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Ditch your version manager

#71

Post by dmitriid »

rossmohax wrote: post #67
throwaway984393 wrote: post #56

First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. Second, to use this package manager, you first need to install direnv . How do you install it? with brew , a different package manager. Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first. Fourth, finally…

It's not about what is possible, it is about ergonomics. We could have used email for conversations online, yet we use Slack. Other tool require lots of thought and carefull execution for what Nix gives you for free.

> Other tool require lots of thought and carefull execution for what Nix gives you for free.

How do I pin ruby version to 2.6.3 in Nix? This is given to me for free in other tools. As are reproducible builds because all modern package/dependency managers lock versions.

Re: Ditch your version manager

#72

Post by kiryin »

In my experience, Nix and Guix are nice toys, but I'm just not ready for the kind of lifestyle change they require to actually use them for anything. For me, "pinning" a package to a specific version means not downloading and building a newer version.

Re: Ditch your version manager

#73

Post by rossmohax »

dmitriid wrote: post #71
rossmohax wrote: post #67

Earlier quoted context omitted.

It's not about what is possible, it is about ergonomics. We could have used email for conversations online, yet we use Slack. Other tool require lots of thought and carefull execution for what Nix gives you for free.

> Other tool require lots of thought and carefull execution for what Nix gives you for free. How do I pin ruby version to 2.6.3 in Nix? This is given to me for free in other tools. As are reproducible builds because all modern package/dependency managers lock versions.

It is not the same level of reproducibility like Nix and Bazel provides.

You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays

Re: Ditch your version manager

#74

Post by topspin »

kiryin wrote: post #72

In my experience, Nix and Guix are nice toys, but I'm just not ready for the kind of lifestyle change they require to actually use them for anything. For me, "pinning" a package to a specific version means not downloading and building a newer version.

In work-a-day devops containers have solved the bulk of the problems functional package managers aimed to solve in the first place.

Re: Ditch your version manager

#75

Post by clhodapp »

throwaway984393 wrote: post #62
IceWreck wrote: post #20

Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. But here we are, some projects only give development instructions based on containers, others support only container based deployment. You need to go out of the way trying to convert dockerfiles into regular install/setup instructions. Containers are great and all, they s…

"Supporting multiple versions" is a misnomer. You can't use multiple versions of a dependency on a single system without completely separating both the build-time and run-time environments, which is what containers do. If Nix did that implicitly it would mean that the applications would all have to be patched - not only to load specific library versions, but to call exec() on specific versions of binaries of complete…

They don't all have to be patched, they just have to be rebuilt in a carefully-controlled environment.

Nix installs everything that it manages (libraries, applications, even managed conf files) under a path that is derived from its exact build description (it's a hash plus some extra stuff to help humans identify what the component is by inspection). This allows, e.g., two different versions of Firefox or two different versions of zlib to exist on the system at the same time. Because the exact build description for the application refers to the exact build description for its dependences, there's a certain Merkle Tree like sense to it where if you were to e.g. rebuild Firefox against a different version of zlib, your resulting Firefox build would have a new build description hash and thus a new path.

An example of what an executable path might look like is: /nix/store/v5sv61sszx301i0x6xysaqzla09nksnd-hello-2.10/bin/hello

Stuff like autotools can actually generally support all of this without patching. In the case that the user wants to run a binary built for a non-nix system outside of a container on a nix system, binary patching does become necessary, in the form of appending to the RPATH of the executable. Nix does provide tools to eliminate as much pain as possible from this process.

It is worth noting that you can still only have one version of a program on your PATH with the canonical name at once.

As far as programs invoking each other with exec: that establishes no requirement at all that the invoked program be using the same versions of libraries as the invoking program. Programs packaged with nix sometimes "purely" refer to each other by their full paths. Other times, they discover each other "impurely" by just searching the PATH.

Re: Ditch your version manager

#76

Post by Groxx »

a-dub wrote: post #18

woah this direnv thing is neat

I've been using it at work for a couple years now, across tons of projects and multiple languages/runtimes/etc.

Very highly recommended. It's fast, safe, and effective. Much, much better than the various nvm/rvm/rbenv/etc that came before it, and it takes no effort to integrate.

Re: Ditch your version manager

#77

Post by throwaway984393 »

mikeyjk wrote: post #48
remexre wrote: post #45

Earlier quoted context omitted.

Most package managers running in containers (whether apt, apk, or something else) aren't built for reproducibility, so doing e.g. `apt update && apt install neovim` can change the versions of libraries inside the container. Furthermore, people don't (in general) write Dockerfiles for reproducibility -- it's very rare to see one where the `apt install` command (or equivalent) has exact version numbers specified for al…

Are there any examples of people doing this? Sounds interesting

    $ VER=$(dpkg -s alsa-oss | grep -m1 '^Version: ' | sed -e 's/^Version: //g')
    $ cat > Dockerfile
That's a complicated example. All you need to do is get a working system, specify the base image tag, run dpkg -l and write down all the versions, then pass them to apt-get install. It's super easy. It's much more complicated to do something like download a static Go app from a specific URL, import a GPG key, validate the key, verify the checksum, etc.

This would freeze all the packages on the system into a file for use in a Docker container:

  $ dpkg -l | awk '{print $2,$3}' | sed -e 's/ /=/g' | tail -n +6 | xargs > packages.txt
  $ cat > Dockerfile
If you just want to find out the dependencies for a package, use something like apt-cache rdepends alsa-oss and then get the versions and pin them. It's pretty trivial to just read the man pages for dpkg or apt and get what you want done.

You commit packages.txt and Dockerfile to a Git repo, and you push your built images to an artifact repository. Test it, validate it, ship it to production. It's all immutable so it doesn't need to be reproduced, you just roll back to the last artifact.

Re: Ditch your version manager

#78

Post by remexre »

throwaway984393 wrote: post #77
mikeyjk wrote: post #48

Earlier quoted context omitted.

Are there any examples of people doing this? Sounds interesting

$ VER=$(dpkg -s alsa-oss | grep -m1 '^Version: ' | sed -e 's/^Version: //g') $ cat > Dockerfile That's a complicated example. All you need to do is get a working system, specify the base image tag, run dpkg -l and write down all the versions, then pass them to apt-get install . It's super easy. It's much more complicated to do something like download a static Go app from a specific URL, import a GPG key, validate the…

Ah, though note there, you want to specify the base image by hash instead of by tag -- I've been bitten by that before...

Re: Ditch your version manager

#79

Post by pabs3 »

nickelpro wrote: post #35
thejosh wrote: post #32

Earlier quoted context omitted.

Most packaging for software was done by the distro and not the actual software authors though right?

Yes, packaging has always been a distro issue never an upstream issue. At the extreme end of this you can look at Arch's saga with Visual Studio Code, since the Arch packagers want to disentangle the .asar app from the specific Electron version it ships inside of (they view Electron as a system library).

Chromium (and thus Electron, although they deliberately lag behind Chromium) has very frequent security updates. While clearly not all of those affect Electron, and not all of those affect every Electron app, some of them will affect Electron and some will affect some Electron apps. While some Electron apps will follow the (deliberately lagging) Electron security update cycle, most developers probably do not update their app for every Electron security update. So it makes sense for distros like Arch to want to ship the security supported Electron version and have every Electron app use that, but maybe all the changes in Electron are breaking apps that use it, so maybe it makes sense to ship one Electron version per Electron app, but then you get an unknown amount of security issues with each app, depending on how out of date the app's Electron version is. So the choice is between a working app with an unknown amount of security issues, or a regularly broken app with fewer security issues. Neither seem like great options to me. Perhaps Electron needs an LTS version to solve this issue.

Re: Ditch your version manager

#80

Post by Arkh4m »

throwaway984393 wrote: post #56

First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. Second, to use this package manager, you first need to install direnv . How do you install it? with brew , a different package manager. Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first. Fourth, finally…

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.

Post reply on HN