Hi, Very late to this party. :-)
On Fri, 20 Feb 2026 at 11:17, Ludovic Courtès <[email protected]> wrote: >> But then consider `guix shell python python-numpy`. That will not >> work. It might be quite nonintuitive. So I am not sure it can be so >> simple. > > Yes, and I agree it’s pretty bad. > > There was a proposal a few years back (by Lars-Dominik Braun IIRC) to > add a package property that would somehow specify which version of a > package should be the default. > > That way, (specification->package "python") would not necessarily return > the package with the highest version number as it currently does, but > could instead return the package that is marked as default. > > Perhaps we need to go in that direction? Well, from my understanding, the status quo seems to add `-next` to the package name when it’s not the default. And to me, the approach is clearer, no? guix shell python-next python-numpy --with-input=python-numpy=python-next The issue Tomas is raising appears to me not about the package name but about the symbol name. And this leads to discrepancy, IMHO. For instance, the symbol libpng-next is named “libpng“ and this appears to me wrong. Because then, guix shell libpng provides libpng version 1.6.50 and not the “default” which is 1.6.39. Somehow, my mental map is of package symbol: • foo/pinned for packages that barely change • foo/pinned can be named “foo” because the version is always older • symbol foo-next and package name foo-next for packages that are not the default; at least not the same package name as the same default package Cheers, simon
