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

51–60 of 155 posts

Re: Ditch your version manager

#51

Post by cwp »

terrywang wrote: post #27
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…

nix is really nice (finding it much better than homebrew cross macOS and Linux) and do good jobs at the best cost for some of my uses cases (kind of binenv / arkade, etc. that manages some binaries that the target hosts use). However, nix has its own problems that I may not qualified to comment (not savvy enough user) - a bit of learning curve (NixOS vs nix package manager) - memory hogging while running system-wide…

The learning curve is the biggest issue. Nix is different, and that makes it hard to learn unless you're already into functional programming. I like it too, but damn, it's so hard to get someone up to speed, even if they're sold on the benefits and want to learn.

Re: Ditch your version manager

#53

Post by Closi »

phendrenad2 wrote: post #7

Managing dependencies is a big problem, and I feel like we've given up on solving it directly, and instead built workarounds. If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn't the latest version of Ruby sufficient? Well, obviously, Ruby's behavior has changed over time. But why isn't it backward-compatible? Why can't I just run Ruby 3.0 with a flag that tel…

> Why can't I just run Ruby 3.0 with a flag that tells it to emulate Ruby 2.6? Or 1.8 for that matter?

I suspect it would be a nightmare - it's not just small parts of the code, it would be other parts of the code that depend on it.

Take for instance Python 2 & Python 3's approach to if ("hello" > "goodbye") - in Python 2 that would be False and in Python 3 that would be TypeError. So if you are running Python 3 with a Python 2.7 flag, how should Python's internal modules that are written in Python 3 handle this? Do all Python's internal modules need to work on every legacy version of Python and load the correct version, or does the interpreter need to somehow load up instructions for both and parse them together? Then there is the whole problem about libraries - are these allowed to selectively choose which version of python they run on?

This is of course only one small example of the complexity - If it was easy to make these things backwards compatible it would be great, but I would expect the cost for implementing full backwards compatibility to be high and the language authors are probably motivated to make people move towards the latest versions.

Re: Ditch your version manager

#54

Post by yewenjie »

ricardobeat wrote: post #52
yewenjie wrote: post #41

Nix Flakes are easier to manage than niv though.

The fact you need a version manager on top of your new, pristine and reproducible version manager is a bit concerning. Can’t whatever shortcomings exist be addressed in nix itself?

Yes, that is what Nix Flakes does. You declare your stuff with a flake.nix and it creates a flake.lock file.

Re: Ditch your version manager

#55

Post by da_chicken »

KronisLV wrote: post #36
nineteen999 wrote: post #29

Earlier quoted context omitted.

> Containers are great and all, they solve many problems but they're not the only solution and theyre definitely not the best solution to every problem. There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. So while the large distros like Redhat and Debian push on with it, the development community only sees Dockerfiles, Snaps, Flatpaks etc.

> There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. I'm one of these developers (at least as far as my day job is concerned) and the only methods of delivery in a professional context that i've seen have been: - delivering .jar or .war application files (Java), mostly through FTP or even e-mail - delivering other files, like documentation e…

> That said, it surprises me that previously no one bothered to set up their own DEB or RPM repositories, since then the clients could use the package management solutions that they're already familiar with. Any idea what are some of the reasons for it? Why doesn't everyone just make it so that their software can be installed and updated through apt/yum/...?

A reflexive, nearly irrational fear of ever, ever installing software outside of the official repositories. Search around for "Frankendebian" and you'll find a lot of people who simply refuse to discuss, let alone support, any individual who has the temerity to actually want to use their computer to run software instead of to simply maintain a pristine operating system.

In other words, the culture treats third party repositories as a pejorative.

Re: Ditch your version manager

#56

Post by throwaway984393 »

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, we get to install a simple Unix program, that any package manager could have provided.

For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. "Reproducibility!" Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic.

And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That's only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers.

Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don't need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else.

Re: Ditch your version manager

#57

Post by blt »

This seems like a good thing for system-level packages, but what about those language-level packages? Could Nix replace both dockerfiles (or a list of apt packages) and pip/conda?

Re: Ditch your version manager

#58

Post by tikhonj »

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…

One thing I like with Nix is that it can build containers, so it's totally compatible with deployment systems that require containers. I don't mean using Nix commands in a Dockerfile, I mean having a Nix derivation that produces a container.

I've been writing normal Dockerfiles at work recently and the whole toolchain is annoying on multiple fronts; I'd love to jump to Nix instead, except it's really hard to convince other people to learn non-trivial technology that's off the beaten path :(.

Re: Ditch your version manager

#59

Post by imatpot »

ricardobeat wrote: post #52
yewenjie wrote: post #41

Nix Flakes are easier to manage than niv though.

The fact you need a version manager on top of your new, pristine and reproducible version manager is a bit concerning. Can’t whatever shortcomings exist be addressed in nix itself?

it's not on top of Nix itself but (about to be) a part of it. according to the NixOS Wiki [1] Flakes is an upcoming feature of the base package manager. it's not part of the stable channel yet, and "proper" documentation only currently exists in the unstable manual [2].

[1] https://nixos.wiki/wiki/Flakes [2] https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni...

Re: Ditch your version manager

#60

Post by tikhonj »

occz wrote: post #43
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…

> Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. Interesting viewpoint! What are your arguments for this being a better solution than containerization?

It's a better solution for dependency management specifically. I need to go to bed so I can't go in too much depth, but here's a high-level summary:

- Nix packages can compose in arbitrary ways, containers can't

- Nix can get much more consistent and granular caching

- once an image is built it's reproducible, but the Dockerfile to run it probably isn't—unless it was written very, very carefully to pin everything—so what happens if you need to update one or two packages in an image?

- not 100% sure here, but it seems that lightweight sandboxing like Nix shells or virtualenvs are a lot more convenient for local development and tooling integration

That said, containers might make more sense for, say, deploying and sandboxing services—that's just a different problem from reproducibly managing dependencies and development environments. Nix can build container images, which lets you get the best of both worlds.

Post reply on HN