4 ms·
As a Guix user/occasional packager who has run into broken packages a few times (including Python ones)... I do wish it had a dependency resolver that could at
by ryukafalz 6y ago
As a Guix user/occasional packager who has run into broken packages a few times (including Python ones)... I do wish it had a dependency resolver that could at least be run outside the build/install process, e.g. when updating libraries.
If I'm updating a library that has a bunch of dependent packages, it's hard to know whether or not something will break downstream. Sometimes this is unavoidable and you really do need to just test everything thoroughly, but sometimes the dependent packages have more knowledge of what library versions they need... and Guix doesn't seem to be aware of this.
- FRidh 6y agoExactly. Python maintainer of Nixpkgs here. What we need is to be able to use a resolver such as included by pip or poetry, to build up our package set. In Nixpkgs this is nowadays unfortunately done manually, and I suppose the same goes for Guix. In Nixpkgs the reason is simple: too eager pinning makes it impossible to resolve a package set that works with the entire set. Now that pip has a resolver what is needed is a way to use constraints not to set only lower and upper bounds, but to enforce a version when resolving. That makes it usable for downstream integrators to construct their primary package set. One could then even make the next step and construct "stable" sets that extend the primary set.