Efraim Flashner <efr...@flashner.co.il> skribis: > I looked over the commit but not deeply enough yet, would it be possible to > use some of the logic in this to fix the package-with-python2 issue?
Nope! > what about extending guix package so you could do `guix package -i $(guix > build foo --with-input=bar=baz) --named=foo-baz`, an on-the-fly custom > package? It’s always been possible to do: guix package -i $(guix build --whatever foobar) but it’s a bit lossy in that ‘guix package’ has to guess the name, version, and outputs being used, and it cannot know metadata such as the package’s search paths. With yesterday’s change, one can directly run: guix package --with-input=foo=bar -i foobar > In terms of figuring out how to make it more lasting, it would need to be > expanded if someone wanted to add/remove an input in their GUIX_PACKAGE_PATH > and have it propagate through the packages without having to make a custom > version of each one. Or to use as a substitute like when libpng had its CVE. To preserve these transformations across upgrades, we’d have to write them in profile manifests. This introduces versioning complications (what if the transformation mentioned in the manifest no longer exists when you upgrade, or what if its on-disk format has changed, etc.) Honestly, I’m not sure it’s a good idea to go this far. I’d rather have people write package variants they care about in a Scheme file. Thoughts? Ludo’.
