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.
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?
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.
E.g. say astropy (=package A) instantiates an a numpy array (C) and
passes it along to scipy (B) to calculate statistics. In that case both
numpy packages need to be the same, to ensure that numpy will recognize
the object as a numpy array, since otherwise it will be an object of a
'different library'.
But e.g. if package C is simply used to show a progress bar (like tqdm),
and those are never shared, then it is probably fine if A and B each use
a different version. (But who knows; maybe tqdm has a global
configuration that is now broken.)
Theoretically, any problems should be caught by the test suite of
package A. But I would be very reluctant to rely only on the test suites.
Second,
that Python packages are normally tested against a specific dependency
version and should strive to use this version and should strive to use
this version and this may easily conflict with other packages
That is not true in my experience: packages are usually tested against a
matrix of different package combinations. At least they should, to some
extent.
Packages should work within the full range of dependencies they allow.
Otherwise it would become impossible to combine them.
I test my Python packages with a preferred set of dependencies, the
lowest versions that should work, and with the latest versions.
third that there are valid reasons to
mix package versions in the same profile, e.g. for testing reasons.
Can you elaborate? I cannot think of any reason why I would want the
same Python package multiple times in the same profile. How would I know
which one will be imported?
Hugo
