[Catalog-sig] PEP 345 Update

P.J. Eby pje at telecommunity.com
Wed Oct 6 19:17:56 CEST 2010


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.


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

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.

Or, you know, we could just let people find out at installation time, 
and complain to the package author(s), like they do now.  ;-)

(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?


> > Of course, in either case the field must still be for human consumption
> > (and tool warning messages) only.  If a developer declares a dependency
> > on an obsolete package, they should be notified; but an end-user who's
> > merely installing the package in order to satisfy another package's
> > requirements doesn't need to be warned.
>
>I think it's a good deal, and we could this way add such a check in the
>distutils2 "check" command. That way, it'll allow people who want to
>rely on "obsoleted" dists to do so.

Makes sense to me.



More information about the Catalog-SIG mailing list