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

131–140 of 155 posts

Re: Ditch your version manager

#131

Post by aidenn0 »

takeda wrote: post #95
zaSmilingIdiot wrote: post #33

Looks interesting enough... But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed? From what I understand this would require an update to the Nix version that supports it... but that also potentially means bumping o…

There are multiple ways of doing it. The obvious one (updating nixpkgs) you already mentioned. Second way is to override[1], in documentation they are showing how to change compilation parameters, but you can also use this to change version of dependencies or source tarball for the package. As you use Nix you will eventually need to do it as sometimes package was not updated, or perhaps you need to use older version,…

4th way is to just package it yourself and use pkgs.callPackage to add it. Overlays are nice for the whole system or if you're still using nix-env, but I find it more clear to use callPackage directly when I'm explicitly building an environment.

Re: Ditch your version manager

#132

Post by aidenn0 »

ricardobeat wrote: post #47

I had the feeling this would be an ad for Nix after reading the first few paragraphs. Is there really a difference from the Docker example given (“your Ubuntu version is EOL”) though? Any of your language or tools can be EOL’ed even if installed via nix, and you have the exact same problem in your hands.

As long as you can track down a source-file with the same sha, you can reproduce the build. I've had very old nix expressions fail to build after clearing my cache, but it was usually fixed fairly simply by changing a URL from http://example.com/release/foo-x.y.z.tgz to http://example.com/archive/foo-x.y.z.tgz

When that wasn't doable, I could google the name of the .tgz file, download a couple and find the one with the matching hash, drop the .tgz inside the directory and change the source to a relative path. Actually I do this even in the "release -> archive" case because "Move a URL once, shame on you. Move it twice, shame on me."

[edit]

If you really don't want to change the .nix expression, you can manually add the file to the cache, and things will Just Work.

Re: Ditch your version manager

#133

Post by takeda »

aidenn0 wrote: post #8
RcouF1uZ4gsC wrote: post #5

Does this work on Windows? For me, the version manager that provides the nicest experience cross-platform is Cargo from Rust. It can specify and pin specific versions. It is super easy to give to a fellow developer and have them reproduce the build. In addition, because Rust is suitable for low-level, high performance work, many times all the libraries you actually need are written in Rust and everything works very s…

Nix is very unixy so it probably could be made to work on WSL, but not native windows. Yes, if all of your dependencies are written in a single language, you can use the language-specific version manager. TFA was pointing out a solution that work across different languages.

It works on WSL but works better on WSL2. WSL is missing some linux functionality like locking this causes sqlite3 to potentially corrupt the data.

Re: Ditch your version manager

#134

Post by Arkh4m »

ducktective wrote: post #130
Arkh4m wrote: post #127

Earlier quoted context omitted.

Here's an example https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5... I used this tool to find the specific nixpkgs version https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable...

Thanks. What if we want `ruby 2.3.1` not in any nixpkgs channel?

Then you'd have to learn to read Nix expressions. The original expression that builds all ruby versions is here: https://github.com/NixOS/nixpkgs/blob/6120ac5cd201f6cb593d1b... Here's an example that shows how to build a customized version for NodeJS https://www.breakds.org/post/nix-shell-for-nodejs

Re: Ditch your version manager

#135

Post by zepolen »

ducktective wrote: post #130
Arkh4m wrote: post #127

Earlier quoted context omitted.

Here's an example https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5... I used this tool to find the specific nixpkgs version https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable...

Thanks. What if we want `ruby 2.3.1` not in any nixpkgs channel?

I'm not on the nix train but this affects rvm too if a particular version isn't available.

Re: Ditch your version manager

#136

Post by moondev »

marcus_holmes wrote: post #96

Now can we solve the problem of installing a program by curl'ing a script from the internet to shell? (bonus points for requiring sudo too)

Run it in a container or vm with cloud-init if ultra paranoid. Multipass makes it easy to cloud-init throwaway vms

Re: Ditch your version manager

#137

Post by takeda »

aidenn0 wrote: post #131
takeda wrote: post #95

Earlier quoted context omitted.

There are multiple ways of doing it. The obvious one (updating nixpkgs) you already mentioned. Second way is to override[1], in documentation they are showing how to change compilation parameters, but you can also use this to change version of dependencies or source tarball for the package. As you use Nix you will eventually need to do it as sometimes package was not updated, or perhaps you need to use older version,…

4th way is to just package it yourself and use pkgs.callPackage to add it. Overlays are nice for the whole system or if you're still using nix-env, but I find it more clear to use callPackage directly when I'm explicitly building an environment.

Good point, I forgot about that one.

Re: Ditch your version manager

#138

Post by dmitriid »

ducktective wrote: post #121
dmitriid wrote: post #117

Earlier quoted context omitted.

> You can do version pinning with 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 amaz…

Looks like you are right. Relevant issue: https://github.com/NixOS/nixpkgs/issues/93327

It amazes me how many people in that thread keep saying that we shouldn't even want it, that this is not what nix is about, that no one should install historical versions etc.

BTW, another issues linked is from 2015 https://github.com/NixOS/nixpkgs/issues/9682

Given that my question never got an answer in HN (not until I had a discussion with the original article's author on Twitter and he posted this solution), it's clear that:

- this issue still exists

- how to do this is still not properly documented

- no one really knows how to do it in nix

- this extremely common functionality that is literally required for actual reproducible builds is entirely glossed over in all the articles praising nix

Re: Ditch your version manager

#139

Post by dmitriid »

Arkh4m wrote: post #134
ducktective wrote: post #130

Earlier quoted context omitted.

Thanks. What if we want `ruby 2.3.1` not in any nixpkgs channel?

Then you'd have to learn to read Nix expressions. The original expression that builds all ruby versions is here: https://github.com/NixOS/nixpkgs/blob/6120ac5cd201f6cb593d1b... Here's an example that shows how to build a customized version for NodeJS https://www.breakds.org/post/nix-shell-for-nodejs

We had this discussion on twitter, so we probably shouldn't repeat it here :)

But more-or-less this is a takeaway: https://news.ycombinator.com/item?id=28602561

Re: Ditch your version manager

#140

Post by dmitriid »

jbboehr wrote: post #119
dmitriid wrote: post #107

Earlier quoted context omitted.

> 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. Hun…

> Hunting down every commit hash of every package to pin down the exact version is neither maintainable nor scalable I believe flakes will make this a lot easier, but it's not quite here yet.

> I believe flakes will make this a lot easier

Somewhat, I guess? It will apparently let you write this:

  {
    inputs = {
      home-manager.url = "github:nix-community/home-manager";
    };
  }
where you can manually point to a specific commit/branch for a tool.

Better than nothing, I guess :)

Post reply on HN