[Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]

[PJ Eby]

On Sat, Dec 8, 2012 at 10:22 PM, MRAB <python at mrabarnett.plus.com> wrote:
> On 2012-12-09 01:15, Steven D'Aprano wrote:
>>
>> On 09/12/12 08:14, MRAB wrote:
>>
>>> If package A says that it conflicts with package B, it may or may not
>>> be symmetrical, because it's possible that package B has been updated
>>> since the author of package A discovered the conflict, so it's
>>> important that the user is told which package is complaining about the
>>> conflict, the one that is being installed or the one that is already
>>> installed.
>>
>>
>> I must admit than in reading this thread, I'm having a bit of trouble
>> understanding why merely *installing* packages should lead to conflicts.
>>
> [snip]
> Personally speaking, I was thinking more about possible problems at
> runtime due to functional conflicts, but it could apply to any
> (undefined) conflict.

If it's for a runtime functional conflict, there's no need for
installation tools to worry about it, except perhaps in the case where
a single project C depends on *both* A and B, where A and B conflict
with each other.  Apart from that piece of information, there is no
way to know that the code will ever even be imported at the same time.
 (And even then, it's just a hint of the possibility, not a
guarantee.)

Nick, OTOH, says that the purpose of the field is to declare that mere
side-by-side installation invalidates developer support for the
configuration.

However, the widespread confusion (conflicts?) over what exactly the
field is supposed to mean and when it should be used suggests that its
charter is not nearly as clear as it should be.

It seems perhaps it is suffering from the so-called "Illusion of
Transparency", wherein everybody looks at it and thinks that it
*obviously* means X, and only a fool could think otherwise...  except
that everyone has a *different* value of X in mind.

That's why I keep asking for specific, concrete use cases.  At this
point, for the field to make any sense, there needs to be some better
idea of what a "runtime" or "undefined" conflict is.  Apart from file
conflicts, has anybody identified a single PyPI package that would
make use of this field?  If so, what *is* that example, and what is
the nature of the conflict?

Do any of the distro folks know of a Python project tagged as
conflicting with another for their distro, where the conflict does
*not* involve any files in conflict?

(And the conflict is not specific to the distro's packaging of that
project and the project in conflict?  i.e., that it would have
actually been possible and/or meaningful for the upstream developer to
have flagged the conflict in the project's metadata, given the
proposed metadata standard?)