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

101–110 of 155 posts

Re: Ditch your version manager

#101

Post by rvanlaar »

dmitriid wrote: post #85
rossmohax wrote: post #73

Earlier quoted context omitted.

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

> It is not the same level of reproducibility like Nix and Bazel provides. What is "the same level"? > You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays That page says: "Overlays provide a method to extend and change nixpkgs" I don't want to change something. I want to simply pin a version. This is neither simple, nor scalable, nor maintainable (also here: https://news.ycombinator.com/i…

Reading your linked post, it seems you are wrestling with how Nix works.

Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do.

As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?

Re: Ditch your version manager

#102

Post by rvanlaar »

dmitriid wrote: post #69

The more I see posts praising nix, the more I am confused by the decisions made. In this post: --- start quote --- How about a different version of Ruby or Node? Let’s say that our project depends on Ruby 2.6 and Node 10. We can go and search for those specific versions --- end quote --- So, to begin with, we still need a "version manager", because we want specific package versions. But look at how this is implemente…

Nix is not easy nor simple. It's complicated but not complex.

re: ruby version In ubuntu I can only install ruby2.7 and I don't which minor version. [1] I would need to use rvm anyway. It's the same with nix. What is possible is to pin the version you need by specifying the commit. [2] shows the diff of the commit that moved ruby_2_7 from 2.7.3 to 2.7.4.

Say for example ruby 2.7.4 has a regression and the project needs to stay on 2.7.3. The revision has for 2.7.3 is used.

[1] > apt search ruby |egrep "^ruby2|^ruby3"

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

ruby2.7/hirsute-updates,hirsute-security 2.7.2-4ubuntu1.2 amd64 ruby2.7-dev/hirsute-updates,hirsute-security 2.7.2-4ubuntu1.2 amd64 ruby2.7-doc/hirsute-updates,hirsute-updates,hirsute-security,hirsute-security 2.7.2-4ubuntu1.2 all

[2] https://github.com/NixOS/nixpkgs/commit/5f9f17cc11caa07e4a9f...

Re: Ditch your version manager

#103

Post by rvanlaar »

dmitriid wrote: post #99
rvanlaar wrote: post #98

Earlier quoted context omitted.

Last week I had a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore. [1] See that `rev` line in the sources.json? The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what. That alone resolves a huge category of potential problems. There's much, much more to it. Nix stores each package in its own path. [2] This m…

> a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore > The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what. If that commit is still available. This still doesn't answer the question of how I easily pin a version. The package versions in the post point to what amounts to a random package version. And that's…

> If that commit is still available.

Why wouldn't it be available? Nix packages are on github. [1]

> And that's on top the fact that "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"

That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post a whole later you'll probably get a newer version.

[1]https://github.com/NixOS/nixpkgs

Re: Ditch your version manager

#104

Post by shantnutiwari »

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…

I've heard about nix here often, but everytime they show toy examples.

And if you want to do anything complicated, it's all get this hash, use this trick, this extra tool etc etc.

At which point, it's just easier to stick with what you have.

>> a distro for hobbyists who tell themselves they're advanced while all the professionals use something else.

yeah, getting the same vibe. Lots of hype not backed by any evidence.

For me, to start off, I'd like to see a real example, not some made up simple use case

Re: Ditch your version manager

#105

Post by hda111 »

Good introduction to Nix. I wish I would have had this when I started.

But what do they mean with “works forever”? What if the Git repo or Web server of the project is gone in several years? How do you reproduce it? Does niv include a local source code mirror?

Re: Ditch your version manager

#106

Post by dmitriid »

rvanlaar wrote: post #103
dmitriid wrote: post #99

Earlier quoted context omitted.

> a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore > The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what. If that commit is still available. This still doesn't answer the question of how I easily pin a version. The package versions in the post point to what amounts to a random package version. And that's…

> If that commit is still available. Why wouldn't it be available? Nix packages are on github. [1] > And that's on top the fact that "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" That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post…

> Why wouldn't it be available? Nix packages are on github. [1]

1. Git history can be re-written.

2. Nix packages still point to some specific versions that may or not may be available [1]

So how exactly is nix so much different from "a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore"?

> That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post a whole later you'll probably get a newer version.

That is only true insofar as you use a "get me the latest version of the package, regardless".

In any sane system the solution to that is to do `npm install ` or `gem install ` or `pip install ` or `brew install `

In nix, apparently it is:

- find the commit hash of the nix package channel

- pull a package that still points to a rather random version

Which raises another question:

nixpackages 21.05's ruby_2_6 is actually ruby 2.6.8. It's not available in nixpackages 20.09. But 21.05 doesn't contain the newer Go versions.

So, if I wanted ruby 2.6.7 and go 1.13 (neither are available in either 21.05 or 20.09), I would do what exactly? Or if I wanted ruby_2_6 (available in 21.05) and go_1_16 (available in 20.09)? All other package/dependency management tools don't even have such a problem.

So far I've asked this at least three different times, and every time the question been ignored or avoided. But sure, nix is amazing, and is a reproducible build system unlike any other.

It's been around for at least 18 years. You'd think there would be easy answers to these questions by now.

[1] Example, https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

Re: Ditch your version manager

#107

Post by dmitriid »

rvanlaar wrote: post #101
dmitriid wrote: post #85

Earlier quoted context omitted.

> It is not the same level of reproducibility like Nix and Bazel provides. What is "the same level"? > You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays That page says: "Overlays provide a method to extend and change nixpkgs" I don't want to change something. I want to simply pin a version. This is neither simple, nor scalable, nor maintainable (also here: https://news.ycombinator.com/i…

Reading your linked post, it seems you are wrestling with how Nix works. Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do. As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?

> Reading your linked post, it seems you are wrestling with how Nix works.

Not only me.

> That's because it's solving slightly different problems than package managers currently do.

We keep hearing this claim, and hardly any proof of that.

> As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?

1. Commit hashes are not versions

2. Hunting down every commit hash of every package to pin down the exact version is neither maintainable nor scalable

Re: Ditch your version manager

#108

Post by AnIdiotOnTheNet »

Closi wrote: post #53
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…

> 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?

If the software has been changed so much you cannot be backwards compatible anymore, name it something else and avoid the conflict and confusion.

Re: Ditch your version manager

#109

Post by globular-toast »

throwaway984393 wrote: post #92
takeda wrote: post #87

Earlier quoted context omitted.

> First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. This is not true. The defining point about Nix is that it allows to define all dependencies explicitly. Every derivation in it is built inside of a sandbox with no access to network and restricted filesystem. This ensures that nothing is accidentally missed. Package management is just one of features. > Second, to use…

> Because the starting state and all dependencies are known it can always create the same result, that's the biggest selling point of Nix to me. And you can do that with the package manager of any Linux distro today. It sounds like Nix's biggest selling point is it does something we can already do.

You can pretty much say the same thing for any new technology. Flushing toilets? But I can already empty my chamber pot far away from my house! The fact is, even if current package managers can do this, people (including professionals) don't do it. The way forward isn't to develop new tooling that works with human nature, not against it.

Re: Ditch your version manager

#110

Post by dmitriid »

rvanlaar wrote: post #102
dmitriid wrote: post #69

The more I see posts praising nix, the more I am confused by the decisions made. In this post: --- start quote --- How about a different version of Ruby or Node? Let’s say that our project depends on Ruby 2.6 and Node 10. We can go and search for those specific versions --- end quote --- So, to begin with, we still need a "version manager", because we want specific package versions. But look at how this is implemente…

Nix is not easy nor simple. It's complicated but not complex. re: ruby version In ubuntu I can only install ruby2.7 and I don't which minor version. [1] I would need to use rvm anyway. It's the same with nix. What is possible is to pin the version you need by specifying the commit. [2] shows the diff of the commit that moved ruby_2_7 from 2.7.3 to 2.7.4. Say for example ruby 2.7.4 has a regression and the project nee…

> re: ruby version

I hoped you would tell me how to pin a specific version in nix, and you didn't. So far, I've asked this question at least three times. This question is either avoided or ignored. Ah yes. There's one "solution" with overlays which is neither maintainable nor scalable.

> ruby version In ubuntu

Is nix ubuntu?

> What is possible is to pin the version you need by specifying the commit.

Commit hashes are not versions

> I would need to use rvm anyway. It's the same with nix

We keep hearing the claim that nix is about builds. Builds often need their dependencies pinned to specific versions. If I still need to use rvm with nix, what's the point?

This is especially funny in the context: we're in the comment section to a post claiming that we should ditch our "version managers" while providing an alternative that, so far, looks to be significantly worse at what it claims to do.

Post reply on HN