Live data from Hacker News

Ditch your version manager

juliu.is

151–155 of 155 posts

Re: Ditch your version manager

#151

Earlier quoted context omitted.

Sorry if I may have come up as a Nix professional/proponent. I'm actually a nix beginner and as can be seen in this thread, I've asked the author similar question to yours. Using Ubuntu, I have been bitten by glibc and other dependency mismatch in my projects and I'm looking for something more elegant than docker/VBox. I've read posts from both sides of this discussion. > Oh. Wait. There's literally no such way. I th…

>> Oh. Wait. There's literally no such way. > I think there is? There is no official way to do that. There's no history. There are no tools in nix to do that. As you noted, you have to rely on the kindness of strangers to provide this service. Here's lazamar's own explanation why he built the tool: https://lazamar.github.io/download-specific-package-version-... Look at the beginning of the "automating" section to see…

But the Nix way (how alien and complicated) is the theoretical sound way of handling dependencies. The docker solution is a blanket over a mess.

Hopefully, documentation and tooling can be improved for a theoretically good but badly implemented solution. The other way around is not possible.

Re: Ditch your version manager

#152
post #149

Earlier quoted context omitted.

That's the point: without using Nix, you'd have to do LD_LIBRARY_PATH hacking to have two programs use two different versions of glibc. When people say "oh nix looks so complicated I can do this using bash scripts" I reply "well show me these beautifully expressive and simple bash scripts then".

I updated my reply. Can you confirm that inheriting from a forked nixpkgs with a patched default.nix in ruby directory is the solution for cases that a particular version was not ever present in history?

There is no need to literally fork the nixpkgs repo. Most language derivations were written with the idea of supporting multiple versions at the same time. In this guide (https://www.breakds.org/post/nix-shell-for-nodejs), the key example is this one:

    let pkgs = import  {};

        buildNodejs = pkgs.callPackage  {};
        
        nodejs-8 = buildNodejs {
          enableNpm = true;  # We need npm, do we?
          version = "8.17.0";
          sha256 = "1zzn7s9wpz1cr4vzrr8n6l1mvg6gdvcfm6f24h1ky9rb93drc3av";
        };
    in pkgs.mkShell rec {
      name = "webdev";

      buildInputs = with pkgs; [
        nodejs-8
        (yarn.override { nodejs = nodejs-8; })
      ];
    }

where we import the normal nixpkgs, then we use `callPackage` to re-use the code that was written by the Nix mantainers, and we specify our own version and SHA.

If the derivation hadn't been written to be reusable what you can do is to copy this whole directory https://github.com/NixOS/nixpkgs/tree/nixos-21.05/pkgs/devel... to your local project and import the nix files locally. In this case, some of the artifact might be missing from the nix cache and you might need to compile some from source. We do this in some cases and upload the artifacts to our private store on https://www.cachix.org so that no engineer has to recompile them again on their own computer.

Re: Ditch your version manager

#153

Earlier quoted context omitted.

>> Oh. Wait. There's literally no such way. > I think there is? There is no official way to do that. There's no history. There are no tools in nix to do that. As you noted, you have to rely on the kindness of strangers to provide this service. Here's lazamar's own explanation why he built the tool: https://lazamar.github.io/download-specific-package-version-... Look at the beginning of the "automating" section to see…

But the Nix way (how alien and complicated) is the theoretical sound way of handling dependencies. The docker solution is a blanket over a mess. Hopefully, documentation and tooling can be improved for a theoretically good but badly implemented solution. The other way around is not possible.

> But the Nix way (how alien and complicated) is the theoretical sound way of handling dependencies.

The approach may be sound, but the implementation and the user experience is atrocious, and can be quite easily[1] improved.

[1] Easily as in: there have been multiple suggestions on what should be done to improve experience, but nix's codebase may not be conductive to that https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-7... and nix contributors don't even see this as an issue https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-6...

Re: Ditch your version manager

#154
post #149

Earlier quoted context omitted.

Sorry if I may have come up as a Nix professional/proponent. I'm actually a nix beginner and as can be seen in this thread, I've asked the author similar question to yours. Using Ubuntu, I have been bitten by glibc and other dependency mismatch in my projects and I'm looking for something more elegant than docker/VBox. I've read posts from both sides of this discussion. > Oh. Wait. There's literally no such way. I th…

That's the point: without using Nix, you'd have to do LD_LIBRARY_PATH hacking to have two programs use two different versions of glibc. When people say "oh nix looks so complicated I can do this using bash scripts" I reply "well show me these beautifully expressive and simple bash scripts then".

Funny how you're talking about how horrible it is to install glibc, when the entire reason lazamar's tool exists is that he couldn't figure out how to install a specific version of a tool using nix https://lazamar.github.io/download-specific-package-version-...

"Why do you look at the speck of sawdust in your brother’s eye and pay no attention to the plank in your own eye?"

Also, not all of us depend on glibc or changes in glibc. Making this solely about glibc while ignoring the larger issue is... can't find a proper word for it.

(and of course there are issues with glibc in nix as well, https://discourse.nixos.org/t/clarification-on-package-names... because glibc is weird in itself)

Re: Ditch your version manager

#155
post #87

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, 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…

> Docker promised to reproduce developer's environment to production. What it did was to zip developer's computer and deploy it.

Yeah, well, that does reproduce the developer's environment, doesn't it?

Post reply on HN