Heya,
Hugo Buddelmeijer via "Development of GNU Guix and the GNU System distribution." <[email protected]> writes: > Hi Reza, > > Thanks for your answer. > > I conclude that it is worthwhile to explore the use of inputs for the > dependencies of Python packages. Because it could perhaps be useful, in > particular for stand-alone applications. And because it should be > strictly a superset of capabilities, we can still use propagated-inputs > if that would be better. But this is already used for standalone applications. Those do not use propagated inputs. Only libraries use propagated inputs. That's how python expects it. Without changing python itself or patching the libraries we won't do much here. And the patching might be unexpected by users. Then you wouldn't be able to just use `import numpy`, you would need `import numpy-1234` or something. > > Nevertheless, I'm worried that we won't know in practice when we should > use which input. Using inputs will lead to many broken packages if it is > not done very carefully. > > On 1/27/26 20:35, Reza Housseini wrote: >> It may be true that most Python packages should use the same lower >> dependency versions in a profile, but I think first that this it is >> not the role of propagated-inputs to enforce this behavior. > > Fair enough, consistency checks is not the primary purpose of > propagated-inputs. But then, what mechanism should verify consistency? I would argue it is one of the features it gives us. The propagated inputs are mapping to the model of python where just one library version is allowed to be in memory in runtime. As long as this is not changed, I would argue changing from propagated-inputs to inputs is dangerous, because it's unknown what version you will use. The profile checks are ensuring this is what happens, that we're using python properly. If this was somehow solved that you could load multiple versions of a given Python module in memory, though, then it wouldn't matter how many different versions you have in your profile. And then using inputs would be the correct way and there would be no point in checking anything in the profile. > > Eg. assume a triangle of dependencies: package A (astropy) depends on > package B (scipy), and both depend on package C (numpy). > > Then there that raises these questions: > - How do we decide whether A and B need the exact same version of C? > - How do we enforce that? > > Note that in other Python environments (venv, conda, poetry, uv), there > will only ever be one version of C. We are introducing a new problem. Exactly. Which is why I am wondering, why are you proposing this in the first place? Typically in one python environment you're expecting to have just one version of a package. Now, you're introducing another level of complexity. Why not ask ourselves the easier question. How do we break the propagation to user profiles? And I think the answer is quite simple, we have basically two cases, for packages, we already do use it, we just change the propagated-inputs to inputs. And we're done. The package can now live in the profile of the user without any issues. It is wrapped with the correct modules, similar to other applications that can live in the same profile, with various library versions. The versions can be conflicting but they are never used together in the same process. So it's all fine. As for development environments, not applications, the answer also seems to me to be quite simple. We already do have a tool for breaking propagation. It's profiles. For example here one can take inspiration from Nixpkgs. They have a function that builds a python environment, giving you out a python executable that has the packages you want. This breaks the propagation of python libraries further. (nixpkgs also uses propagation of python modules) Something similar can be made in Guix, I have already started working on a first iteration here: https://codeberg.org/Rutherther/ruthless-guix/src/branch/main/modules/ruthless/environment.scm. This makes a package with executable named as you choose, ie. `python3-science` that would have numpy, pandas, scipy and so on. That executable would start python with the packages of your choosing. The resulting profile you put this package to has no GUIX_PYTHONENV, so there is no potential for conflicts. And you can have multiple python versions coexisting, each with its own set of libraries. Rutherther
