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

Nix: Taming Unix with Functional Programming

tweag.io

Post reply on HN
Print view View original

121–130 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#121

Post by easygenes »

pxc wrote: post #55
mattarm wrote: post #40

Earlier quoted context omitted.

> it just needs to be manually enabled under 'experimental-features' Same with flakes. My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults."

> My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults." I think probably both. The Nix community is host to very diverse and partially overlapping experimentation, and features like rollbacks and version pinning make the bleeding edge feel relatively safe, further fostering such experimentation. The new Nix CL…

FWIW, I'd say the new Nix CLI should see broader adoption soon. It was only just around the beginning of 2022 that they started signaling it was mature and there's been good progress to improve things like Home Manager compatibility with the new session format brought with the new CLI since.

I think mostly now a few people just need to step up to overhaul the docs.

Re: Nix: Taming Unix with Functional Programming

#122

Post by wdkrnls »

goosedragons wrote: post #16
jnxx wrote: post #14

Earlier quoted context omitted.

I am not sure, but it is possible that R want to be its own package manager which interferes with Guix? A similar problem seems to appear in Python, where there on Distributions like Debian there is kind of a struggle which package manager - the system-defined packages, or the user-defined ones like pip - have the last word. I have used Guix a bit with Common Lisp libraries, and that works like a charm. I also found…

R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.

I have not experienced that for what it's worth... atleast not after I rebuilt the whole profile.

Re: Nix: Taming Unix with Functional Programming

#123

Post by infogulch »

octoberfranklin wrote: post #91
xyzzy_plugh wrote: post #50

Earlier quoted context omitted.

Hydra is arguably one of the scariest parts of Nix: A giant, bespoke CI system written in C++. Arguably it shouldn't exist. Nix can and should easily slot into any CI tool.

And, unlike nixpkgs, Hydra is pretty unfriendly to contributions. There is one master trusted public key for nix: 6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= It is hardwired into the nix source code and every (unpatched) build of nix from the last decade or so. There is no revocation system. There is no public key infrastructure. If that key gets compromised, there is no backup plan. I love Nix, but this is batshit…

> There is one master trusted public key .. It is hardwired into the nix source code .. There is no revocation system .. The Hydra instance has access to the private key

> it is built in C++

Re: Nix: Taming Unix with Functional Programming

#124

Post by Macha »

revscat wrote: post #120
noahmasur wrote: post #90

Earlier quoted context omitted.

What happens when you have two projects that use two different versions of the same dependency? With Nix, you can "install" many different versions of the same program side by side in the store, and then "activate" the one you need at runtime (or with direnv).

Has never happened. I know this is something that is given as a benefit of Nix, but I have personally never encountered the situation. For every project I have worked in professionally their tool chain was standardized enough that the situation never arose. If parallel installations like you describe is a requirement — and I’m sure that it is — then Nix looks like it could help. That’s just not something I have ever…

With node this happens everywhere all the time hence the popularity of tools like nvm or fnm. At my current company we have projects that absolutely require java 8, or 11, and I'm sure we'll soon have Java 17 only projects, sometimes with corresponding needs regarding tomcat or maven etc. versions. It's also a common complaint with python and the most common solution seems to be a bunch of python3.x packages from your package repository, though there have been tools like tox or pyenv for this and others that try to combine solving this problem and virtualenv management.

That said, if you just want language generic toolchain management, asdf seems to have a much lower barrier to entry.

Personally I have been using nix as a homebrew replacement, because it allows me to sync my packages and versions between my personal Arch setup and my day job Mac OS setup with a single configuration

Re: Nix: Taming Unix with Functional Programming

#125

Post by JonChesterfield »

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

Python is _really_ tempting as a build (or test) dependency. It's an easy way to throw together code generators or similar glue that is likely to run on whatever platform is building your software.

Re: Nix: Taming Unix with Functional Programming

#126

Post by baby »

infogulch wrote: post #113
SuperSandro2000 wrote: post #101

Earlier quoted context omitted.

The python ecosystem is not a giant mess, its just dependency hell. You need to work with what you get from upstream. > Nix actually integrates all package updates into one channel which nobody else anywhere does If you are using the python system packages then Arch, Debian and probably more are doing the same. > it's even worse because a lot of projects use python as a build dependency (?!) which then cascades these…

Thank you for your input! What do you think about the linked thread? > The python ecosystem is not a giant mess, its just dependency hell. There are dozens (?) of actively used package and environment management systems, with no consistency and no lockfiles, many packages ignore semver, and having multiple versions of a package installed causes weird issues. I'm not sure why "a giant mess" is an invalid descriptor, I…

I’m guessing you’d just have to create a derivation for the python package you’re trying to use.

Re: Nix: Taming Unix with Functional Programming

#127

Post by pxc »

easygenes wrote: post #121
pxc wrote: post #55

Earlier quoted context omitted.

> My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults." I think probably both. The Nix community is host to very diverse and partially overlapping experimentation, and features like rollbacks and version pinning make the bleeding edge feel relatively safe, further fostering such experimentation. The new Nix CL…

FWIW, I'd say the new Nix CLI should see broader adoption soon. It was only just around the beginning of 2022 that they started signaling it was mature and there's been good progress to improve things like Home Manager compatibility with the new session format brought with the new CLI since. I think mostly now a few people just need to step up to overhaul the docs.

I agree that critical mass with third-party Nix code, especially in important projects like Home Manager and Nix-Darwin, is crucial and it's almost there.

I don't want to rush the finalization of flakes or the new CLI, though, eager as I am to see them come out from behind the 'experimental' flag. There's clearly still a lot of work, including bugfixes, going into the flakes implementation.

Re: Nix: Taming Unix with Functional Programming

#128

Post by baby »

Been using nix for a few weeks and while I feel like it really has some great ideas, here are what my pain points have been:

- not great documentation, especially for newer features like flakes

- nix wants to replace rustup when rustup is already doing great

- nix doesn’t seem to work that well on mac. Not sure if it’s our config our that it’s painful on mac in general

- the biggest issue: it doesn’t work well with tools (vscode, sublime merge, etc.) as you need to launch them within a nix shell and that doesnt work well (at least on mac). Now I’m wondering if it’d make sense to install tools within the flake dev shell…

Re: Nix: Taming Unix with Functional Programming

#129

Post by zaphirplane »

jnxx wrote: post #76
infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

Is the discussion here that Nix doesn’t support multiple side by side installations of different versions making it difficult to install two packages depending on the same package but different versions ?

I thought in Nix you can have that, and python can have venv for independent library versions, is it that no one has done the work to combine the two ?

Re: Nix: Taming Unix with Functional Programming

#130

Post by pxc »

zaphirplane wrote: post #129
jnxx wrote: post #76

Earlier quoted context omitted.

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

Is the discussion here that Nix doesn’t support multiple side by side installations of different versions making it difficult to install two packages depending on the same package but different versions ? I thought in Nix you can have that, and python can have venv for independent library versions, is it that no one has done the work to combine the two ?

Nope. All Python programs in Nix are effectively venv'd, so-to-speak.

The problem is that if two packages A & B each depend on the same library L but they require different versions of it, any Python code that imports both as libraries will end up with two, potentially incompatible, copies of the same library in its import path. And Python doesn't support this, so it uses the same version of L with all the Python code running in that process. So now depending on whether some package P which requires both A and B imports A first or B first, A will end up using B's version of L or vice-versa. This sometimes does nothing, and it sometimes causes very weird, very subtle breakage.

Thus for all of the Python libraries in Nixpkgs to be usable in any combination by any package in Nixpkgs, there can only be one version of each Python library in Nixpkgs.

Once your package collection is large enough, you start actually encountering versioning conflicts as described above in the transitive Python dependencies of your end-user application packages. That's why Linux distros run into these integration issues. Application developers generally don't because their applications development environments are much smaller.

Post reply on HN