[Catalog-sig] PEP 345 Update

[P.J. Eby]

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.

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

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

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.

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.

In other words, none of the above is actually a use-case for having a 
"Conflicts" field.


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


>"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!

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


>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!