[Catalog-sig] PEP 345 Update
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
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