Re: Channel dependencies

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Chris Marusich <cmmarusich@gmail.com> skribis:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> [...]
>>
>>> Chris raises interesting issues.  I think it’s OK to first come up with
>>> an implementation that has some limitations but works with the simple
>>> use cases we have in mind.
>>
>> I’ve fixed this according to what we’ve discussed: when more than one of
>> the user-provided or channel-required channels have the same name we
>> ignore the more recent specification unless it is more specific
>> (i.e. the new channel specification mentions a commit while the former
>> did not).
>
> As long as the "channel resolution mechanism" is deterministic, it's
> probably OK.  But if you have two channels A which depends on C, and B
> which depends on C', where C' is a different version of C, then we can
> arrive in a situation where the author of A tests and provides support
> for their package definitions in the absence of channel B, and the
> author of B tests and provides support for their package definitions in
> the absence of channel A, and a user who wants to use packages from both
> A and B is stuck because one of the channel owners (the one whose
> dependency we didn't pick) doesn't want to support that use case.

Good point.  I agree that it’s similar to the question of propagated
inputs, which we deal with by reporting an error when a collision
arises.

So, similarly, I think the safe way would be to report an error when
channel requirements conflict.

We must define what it means for two <channel>s to conflict:

  • if a channel’s ‘commit’ is #f, then any channel with the same name
    but a different ‘uri’ and/or a different ‘branch’ and/or a non-#f
    commit conflicts;

  • if a channel’s ‘commit’ is not #f, then any channel with the same
    name and otherwise different fields conflicts.

WDYT?

If we have inspiration later, we can liberalize this, for instance by
using several inferiors.  It would be quite a bit of extra work, and
it’s not immediately clear to me how that could work.  I believe what
Ricardo proposes already covers many use cases anyway.

Thanks,
Ludo’.