[Python-Dev] Keyword meanings [was: Accept just PEP-0426] (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Dec 9 06:54:08 CET 2012

On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby <pje at telecommunity.com> wrote:

On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby <pje at telecommunity.com> wrote: >> >> So if package A includes a "Conflicts: B" declaration, I recommend the >> following: >> >> * An attempt to install A with B already present refuses to install A >> without a warning and confirmation >> * An attempt to install B informs the user of the conflict, and >> optionally offers to uninstall A >> >> In this way, any collateral damage to B is avoided, while still making >> the intended "lack of support" declaration clear. >> >> How does that sound? > > > No, that's not the way it works. A conflict is always symmetric, no matter > who declares it.

But that precisely contradicts what you said in your previous email: > It's to allow a project to say > they don't support installing in parallel with another package. Just because A doesn't support being installed next to B, doesn't mean B doesn't support being installed next to A. B might work just fine with A installed, and even be explicitly supported by the author of B. Why should the author of A get to decide what happens to B? Just because I trust A about A, doesn't mean I should have to trust them about B.

If I'm installing both A and B, I want to know if either project doesn't support that configuration. The order in which they get installed should not have any impact on my finding out that I am using one of my dependencies in an unsupported way that may cause me unanticipated problems further down the line.

The author of A doesn't get to decide what happens to B, I do. They're merely providing a heads up that they believe there are problems when using their project in conjunction with B. My options will be:

As a concrete example, there are projects out there that are known not to work with gevent's socket monkeypatching, but people don't know that until they try it and it blows up in their face.

I now agree that enforcing a conflicts field at install time in a Python installer doesn't make any sense, since the nature of Python means it will often be easy to sidestep any such issues once you're aware of their existence (e.g. by avoiding gevent's monkeypatching features and using threads to interact with the uncooperative synchronous library, or by splitting your application into multiple processes, some using gevent and others synchronous sockets). I also believe that any Conflicts declaration should be backed up with an explicit explanation and rationale for that conflict declaration in the project documentation.

Making it impossible to document runtime conflicts in metadata doesn't make those conflicts go away - it just means they will continue to be documented in an ad hoc manner on project web sites (if they get documented at all), making the job of package curation unnecessarily more difficult (since there is no standard way to document runtime conflicts). Adding a metadata field doesn't make sure such known conflicts will be documented, but it least makes it possible.

So, I still like the idea of including a Conflicts field, but think a few points should be made clear:

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20121209/04c746da/attachment.html>

More information about the Python-Dev mailing list