[Catalog-sig] PEP 345 Update

[Alexis Métaireau]

Le 10/06/2010 06:17 PM, P.J. Eby a écrit :
> At 08:39 AM 10/6/2010 +0100, Alexis Métaireau wrote:
>> So we agree there is conflicts that cannot be find a simple way at the
>> installation time (thanks for providing those examples). I agree that
>> the conflict field have to stand for a *possibility* of a conflict.
> 
> I would suggest, therefore, that the conflict field format be changed to
> include a brief human-readable description of the nature of the
> conflict(s), and a URL where the user can obtain more information.
+1 on that.

>> If "foo 1.0" and "bar 1.0" are well known conflicting releases, we could
>> avoid the check of all the files to output an error.
> 
> Of course.  But if we are just caching file-conflict information, then
> perhaps we should just list the files that will be installed, and then
> there is no need for the developer of either package to:
> 
> 1. figure out that the conflict exists,
> 2. re-release their package with the information, and
> 3. keep it up-to-date (and re-release it) when the files change *in
> either package*!
> 
> Let's once again take an actual (historically-occuring) use case:
> PyDispatcher and RuleDispatch.  When both packages were released, they
> included a package named "dispatch", and so somebody downloading both
> would've only detected the problem at installation time.
> 
> Let's say that I responded to this situation by adding a
> "Conflicts-Release: PyDispatcher" to RuleDispatch's distribution.  Well,
> not too long after we both knew about the conflict, the author of
> PyDispatcher actually changed his package name, alleviating the
> conflict...  but (historically) I didn't find out about this until much
> later.
> 
> So then, the Conflicts-Release in RuleDispatch would have been
> incorrect: a user with the newer PyDispatcher installed would be warned
> to *not* install RuleDispatch, even though there's no conflict any more.
> 
> Again, this is a case where the lack of an authoritative third-party
> administering the metadata makes the whole thing a mess.
> 
> Now instead, consider what happens if we simply list the files to be
> installed, or some portion thereof.  Now, the release of a new version
> of PyDispatcher resolves the conflict immediately and transparently,
> without any explicit action by either author, or by the user.  (And it's
> not teaching users to force installation due to widespread inaccuracies
> in the metadata.)
> 
> So, if you review this scenario, what you will see is that using a
> Conflicts-Release field to manage file-level conflicts is actually
> *worse* for EVERYBODY in this scenario, users and developers alike!
> 
> IOW, if you want to gain the benefit of being able to pre-detect
> file-level conflicts, the only safe solution is to have a way to e.g.
> query PyPI for installation manifests, or include some sort of metadata
> for that in the spec.  Expecting the developers to *manually* maintain
> file conflict information (and especially to correct it when the problem
> is resolved!) is not a good tradeoff vs. the minor extra time needed to
> download the file and notice the conflict.
You convinced me :) +1 on that too: add a way to query PyPI for
metadatas manifest, and then check on the system if the files are
already present ot not at installation time. This easy too the detection
of the conflicts when not installing distributions.

> 
> If for some reason it can't be done this way, the alternative would be
> to manually specify something like a Conflicts-Files field that lists
> some filenames known to conflict with certain other packages.  The tool
> doing the fetching can then check whether *those* files are already
> installed.  Then, if I changed RuleDispatch to say there were potential
> conflicts on dispatch/__init__.py, then tools would be able to notice
> that yes, there's a problem, or no, there's not.  And I wouldn't need to
> say *which* other project releases might be conflicting -- once the
> conflict was declared, then any project including those files would
> conflict, and any project that ended its conflict would become
> nonconflicting automatically.
So you mean adding a list of files that could be possibly conflicting ?
I dont get the added value of this way to think over the manual
detection system.

> Or, you know, we could just let people find out at installation time,
> and complain to the package author(s), like they do now.  ;-)
Hmm, that will always be the case, anyway :)

> (Btw: part of the rationale for creating .egg files in the first place
> was that they *can't* have installation conflicts with each other,
> except for scripts...  and scripts weren't part of the original use case.)
> 
> 
>> This lead to another question: Should we use exactly the same fields
>> with the same meanings, depending the context ? I think the answer is no.
>>
>> For instance, we could interpret the "conflicts" field differently if we
>> want to install the software "as is" (in which case I think it's better
>> to trust it), than if we want to use that field in a distro context (as
>> the distros can provide configuration for the python distributions, they
>> can resolve those conflicts). BTW, if we provide a "conflict" field, it
>> can help them to detect such the simple way.
> 
> I don't think I understood either of these paragraphs.  Could you
> elaborate?
Sure,

I'm talking about the fact that the meanings of the fields change
depending on which context they are. For instance, we have to be sure
that the context for the "conflict" field is at *installation* time, not
at *runtime*.

So, I guess, we need to change a bit the PEP to explain the "scope" of
such fields.

I'll try to do that in the next days.

Alexis