> What do you think about the linked thread?

I already posted multiple posts in the thread under the same username. Other than adding important consumers of a dependency to its tests, the only solution I could come up with is to move AI/ML packages into their own repository where they can move at their own pace and do pins/overrides more freely and/or drastically reduce the amount of python packages in nixpkgs.

Semver doesn't really apply here since nix always points at a specific version of each dependency. Multiple package versions are not visible to the same app. And you can include your own lockfile-like list.

So in practice, it's not really a bigger problem for nix than for any other release. If you need to freeze versions for an app, you freeze them. If you don't or if you're packaging a library, you can (usually) rely on automated PR testing to catch breakages and deal with them there.

The thing that you and sibling miss is that this only applies to the one direct dependency on a package, but not on dependencies required by that package. For that you have to work with any build and dependency resolution system that the package or its author uses, and you're up a creek without a paddle if the author doesn't care to help you debug your own system.

I'm not missing this. It's not a problem the way you describe it. With nix you generally choose between packaging with deps that are in the repo, or effectively provide your own list of vendored versions. Both cover all the deeper dependencies and you get the choice of integrating with the project's build system or ignoring it and providing your own lockfile equivalent. (the latter especially if the build does something really weird)

Even if authors are not responsive, nix maintainers provide the required patches or disable the broken functionality. So no, things are mostly ok.

> that this only applies to the one direct dependency on a package, but not on dependencies required by that package

Right now in nixpkgs we manage all dependencies in all packages front to back. So all dependencies of a dependency and dependencies of dependency dependencies and so on.

Uh, what? I've not used Nix with python (so I don't know if there's something particularly bad there), but most of the complexity comes from handling non-python dependencies of python packages (which different people have different needs and hence opinions on, and so seeking consistency there is like expecting all the linux distros to merge). At best there are two major systems that people will talk about (pip+venv and conda), and the reality is conda isn't a python package manager, but a more general system (and every other python system you could name is built on the pip+venv system).

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