[Catalog-sig] PEP 345 Update

[Alexis Métaireau]

 Le 08/25/2010 09:41 PM, P.J. Eby a écrit :
> At 06:45 PM 8/25/2010 +0200, Alexis Métaireau wrote:
>> when two releases propose the same python modules to import,
>
> Installation tools *always* have to detect this anyway -- a conflicts
> field adds nothing new here.
>
> Real world example: RuleDispatch and PyDispatcher both used the
> "dispatch" package name at one point, but would not have if they'd
> known the other existed.  An installation tool would have had to
> detect this, since there was no declared conflict.
True.
>
>> or when they rely on the same configuration files for instance.
>
> What does this mean, for a Python library?  ISTM that it resolves to
> either a file-level conflict, or a user-managed conflict.
You're probably right on this.
>
> Please, please provide an example for "Conflicts" that does *not* fall
> into one of the following categories:
>
> 1. The installed files conflict,
>
> 2. Importing the provided code causes monopolization of a
> process-level resource (e.g. a signal handler, trace hook,  etc.),
>
> 3. The code monopolizes a system-level resource (e.g. a user ID, port,
> directory, etc.)
>
> For category 1, the installation tool has to be able to handle this anyway
Yes, here the conflict field is not needed.
>
> For category 2, the installation tool need do nothing: it is possible
> and sane to have both, say, Twisted apps and asyncore apps installed
> on the same machine -- they will have different startup scripts and
> will not import each other.
If they have not different startup scripts, or if they miss any sort of
"lock" (for instance) to access the files (too bad we dont live in a
perfect world), this means there will be problems while running both at
the same time. As you said, that's not "installation" related, here.
>
>
> For category 3, the user has to take some kind of action to use both,
> and/or is obliged to configure them in such a way as to use different
> resources...  but mere *installation* is not going to cause a problem.
Right, the installation *will not* cause problems, but they will apear
after that. If so, we have two choices:

    - First is to tell nothing to the user about that, and I think
    that's a good option, as it could result in a end user bad
    experience (if that's not handled at the installation level, what
    will handle this?)
    - Second is to prompt the user about what he want to do: Do we have
    to install the release/distribution, even if it can cause problems
    while running them? Are you sure you want to install both, even if
    it could lead to such issues ?, etc.


> In other words, none of the above is actually a use-case for having a
> "Conflicts" field.
I have pain to imagine use cases where conflicts could raise at the
*installation* level too, but the question seems to be: "do we need
something to describe installation-related conflicts, or run-related
conflicts ? In debian apt system, conflicts are described for "on-run"
issues, IIRC.
>
>
>> There is also the example Fred quoted about interfaces, here is the
>> quote:
>
> Fred hasn't yet explained this in a way that shows why it's not one of
> the above three cases regarding Conflicts.
>
>
>> I agree that it would be nice if the way of the relation have been
>> changed, but Merwok pointed out that will force the maintainer of the
>> old release to create a new release just for that.
>
> Here's the thing: so far I'm the ONLY person in the discussion who has
> even offered an example of when Obsoletes would be used...  and for
> the two examples I gave, I would totally be willing to make a new
> release for them to include that field, if there was some benefit
> (e.g. user notification) to having the field.
And that's the use case described in the PEP. So, now, we have to choose
if it's acceptable to make a new release for updating this field, or not.
>
>
>> "Conflict" and "Obsoletes" seems to be needed, here, as they cover
>> different use cases.
>
> As far as I can tell, nobody has given any use cases for Conflicts or
> Obsoletes that are not either:
>
> 1. A mere advisory message, or
> 2. Redundant with normal file installation conflict detection.
>
>
>> If the "Ham" release have been obsoleted by "Egg", and if "Spam"
>> relies on "Ham", and "Ham" is installed, that's fine, and the
>> installation can go on.
>>
>> Now, if we try to install "Towel", that relies on "Egg", and we have
>> already "Ham" installed, we should just state there is a conflict here.
>
> Why is there a conflict?  This makes no sense whatsoever!
Yes, I was wrong there. My bad. This depends if Egg and Ham are
conflicting or not, rather than if one is obsoleting another.
>
> PEAK-Rules obsoletes RuleDispatch, but there is absolutely no reason
> to not install both.
>
> If you disagree with this, then we have a different meaning of the
> word "Obsoletes"...
>
> In which case, you need to show a concrete example of "Obsoletes"
> using REAL Python packages, not made-up foobar examples, in order to
> illustrate the definition where "obsoletes" means "shouldn't both be
> installed".
>
>
>> By that, I mean that the releases should not be replaced by another
>> ones, even if the new ones obsoletes the old one.
>
> In the specific example you gave, there isn't any conflict -- both
> should be installed, and there is no need to even notify the user.
>
> (Note that forked packages using the same API only conflict because of
> *installing conflicting files* -- so if you're thinking of a fork as
> your example here, it is leading you to confuse the ideas of Obsoletes
> and Conflicts.)
>
I was not thinking about a fork, but about a new rename. That said, I
must admit that the difference between the two fields is sometimes hard
to see.
>
>> the "conflict" field covers another type of conflict, also needed: it
>> would just be used in the way: "both A and B releases can't be
>> *installed* on the same time, whatever could be the cause".
>
> The thing I haven't yet seen an example of is why they can't be
> installed at the same time, that doesn't reduce to a file installation
> conflict.  AFAICT, anything else is *necessarily* a runtime conflict,
> unless the intent is to cover installation of more than just scripts
> and their libraries.  (e.g. MvL's example of creating user IDs)
>
> But if that's the case, ISTM we should wait until we have the software
> that does such installations *first* -- PEP 314 is an example of what
> happens when you create the metadata spec before the tools that use it
> -- nobody fills them in much, because they don't know how they'll be
> used or have any reason to, and then the tools probably end up needing
> different metadata anyway!
+1. This series of mails point out that we definitely need to talk a bit
more about the usability of the fields.
Maybe are we missing something here, and maybe arent we talking about
the same type of conflicts. In any case, we need to clarify all this
*before* doing the implementation stuff.

Cheers,
Alexis


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20100826/f7a39940/attachment.html>