Hello, I really like the idea (less irrelevant stuff in the profile is better). One question below though.
Reza Housseini <[email protected]> writes: >> More importantly, it is my understanding that different packages in the >> same profile would be able to use their own version of a specific >> dependency. Because those inputs cannot conflict because they never end >> up in the same profile. >> >> But I don't see how that feature would be useful in practice. E.g. I >> definitely want all installed Python libraries to use the exact same >> numpy installation. I can imagine a whole load of problems with passing >> data around between the-same-but-different-versions of a package. > > In general this boils down to define dependencies globally > (propagated-inputs) or per package (inputs). I argue doing things per package > reduces complexity. > 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. Second, > that Python packages are normally tested against a specific dependency > version and should strive to use this version and this may easily > conflict with other packages and third that there are valid reasons to > mix package versions in the same profile, e.g. for testing reasons. So > in short, this gives us flexibility to use different package versions if > we need to, but still allows us to enforce a "global" dependency version > if we want to. This I do not fully follow. Assuming I have the following packages: (define-public python-foo (package ... (inputs (list python-omega-1)))) (define-public python-bar (package ... (inputs (list python-omega-2)))) (define-public python-baz (package ... (inputs (list python-omega-3 python-foo python-bar)))) When I install the python-baz package and run it from python, what version of python-omega will be used by the Python when it executes `import omega`? Ideally this should be an error during a package build due to conflicting files, but I am unsure if that is the direction you want to take this in. What are your thoughts here? Thank you, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
