Hartmut Goebel <[email protected]> writes:
> Am 31.01.26 um 15:39 schrieb Tomas Volf:
>> The difference is that currently you get a warning during building the
>> profile and (presumably) evaluate its validity and act if necessary. If
>> the conflict will be hidden inside a package(s), the user gets no useful
>> feedback.
>
> I got you: Today, if the packager creates such a conflict, the user gets a
> warning.
>
> IMHO it's a error if a package includes different versions of the same python
> modules as this is bound to cause issues.
Two notes here:
1. Yes, it is an error on the side of the packager, but we all are just
human, and make mistakes. So it would be nice if the build system
enforced no-conflict rule.
2. Even then, there is still a generalized version of the problem.
(define python-foo
(package ...
(inputs (list python-omega-1))))
(define python-bar
(package ...
(inputs (list python-omega-2))))
(home-environment
(packages (list python-foo
python-bar)))
Each individual package is correct, but the resulting profile still has
a conflict. With propagated inputs, user gets a warning. With inputs,
there is no warning, but it is unlikely that both -foo and -bar would be
functional from python in the resulting profile.
I like the idea, I think switching to inputs and having self-contained
packages are good ideas. I just think some safe-guards should be put in
place, enough to at least not to make situation worse than it currently
is.
ntomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
