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’.
