Hello! Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> skribis:
> with the introduction of the collision avoidance feature that prevents > you from installing different variants of the same package into a > profile we made it impossible to install “python” and “python@2” into > the same profile. > > It still works with ad-hoc environments, That’s because we explicitly disable the check in ‘guix environment’ (commit afd06f605bf88a796acefc7ed598b43879346a6b). > but manifests containing both Python versions cannot be instantiated > any more. This is too strict, because we know that these two variants > don’t cause conflicts. More or less: ‘PYTHONPATH’ is version-independent, which I suppose could be problematic. > What can we do to make this feature a little smarter? > > How about a package property that defines a “conflicts?” predicate that > takes two packages of the same name and determines (e.g. by checking the > major version) if these two packages are conflicting? If no such > predicate is provided we assume that packages with the same name cause a > conflict and prevent installation. Unfortunately it wouldn’t work in the general case where some profile entries may be coming from ~/.guix-profile/manifest, as is the case when you do: guix package -i python@2 guix package -i python@3 I would suggest short-term solutions, which are not exclusive: 1. Add a ‘--allow-collisions’ flag to ‘guix profile’ (we discussed it before but didn’t get around to doing it apparently!). 2. Use different package names when we know things can be parallel-installed: “python2” vs. “python” (I’m talking about the package name, not its version string.) That’s what distros usually do, and I think it’s good enough. A longer-term solution would be to add a property like you suggest, except that it should be serializable (a regexp, an sexp, or something), such that we can keep it in ~/.guix-profile/manifest and honor it later. That adds complexity for something we could easily address through conventions. Thoughts? Ludo’.