[ris]

Here we go again. The source of the problems in in toy package managers (and I include all language package managers here) is not just the package managers themselves, it's the "version soup" philosophy they present to the user. Not daring to risk displeasing the user, they will take orders akin to "I'd like version 1.2.3 of package a, version 31.4.1q of package b, version 0.271 of package c, version 141 of package d...", barely giving a thought to inter-version dependencies of the result.

Unfortunately, software does not work this way. You cannot just ask for an arbitrary combination of versions and rely on it to work. Conflicts and diamond dependencies lurk everywhere.

Sensible package systems (see specifically Nix & nixpkgs) have realized this and follow a "distribution" model where they periodically settle upon a collection of versions of packages which generally are known to work pretty well together (nixpkgs in particular tries to ensure packages' test suites pass in any environment they're going to be installed in). A responsible package distribution will also take it upon themselves to maintain these versions with (often backported) security fixes so that it's no worry sticking with a selection of versions for ~6 months.

However, I can't say I'm particularly surprised that these systems tend to lose out in popularity to the seductively "easy" systems that try to promise the user the moon.

[emptysea]

Some background: A few months back I was curious about the nix style of packaging so I setup a python project using nix via nixpkgs' pythonPackages. This worked pretty well, but I kept wondering to myself if it was superior to explicitly declaring each version of a package via npm, cargo, bundler, etc.

The way to "freeze" dependencies seemed to involve using a specific git sha of nixpkgs.

From the point of view of a nix newbie, it seems that by relying on nixpkgs to remain relatively stable, you are at the mercy of your package maintainers who might introduce a backwards incompatible change resulting in a build breaking.

One of the alternatives to this was to essentially copy the nix package descriptions from nixpkgs to a projects repo to ensure that packages are explicitly declared. At this point, it felt as though I was maintaining a .lock file by hand.

Do you think nixpkgs without declaring its specific version i.e., just use pythonPackages.numpy is the best way to use nix for dependency management?

[kalefranz]

There's been quite a bit of discussion about Anaconda and conda in this thread already. Anaconda also takes this distribution approach, and it's targeted specifically at python.

[ris]

Yet it will never be able to solve the system-library dependency problem in the way that Nix does.

[RayDonnelly]

It solves this already and has done for many years (but this depends on what you mean exactly by "the way that Nix does").

[kalefranz]

Can you elaborate? Conda packages have full metadata descriptions for system-level dependencies. I agree with you that conflicts and diamond dependencies lurk everywhere, which is precisely the reason Conda employs a SAT solver.