Home Original page

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

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:
- use them both anyway (e.g. perhaps after doing some research, I may find
out the conflict relates solely to a feature of B that I'm not using, so I
simply update my project documentation to say "do not use feature X from
project B, as it conflicts with dependency A")
- choose to continue using A, find another solution for B
- choose to continue using B, find another solution for A

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:
- the Conflicts field would be for documenting other distributions which
have known issues working together in the same process and thus constitute
an unsupported configuration
- this field would be aimed at package *users*, rather than at installation
tools (although it would still be good if they installation tools supported
scanning a set of packages for known conflicts)
- any use of this field should be backed up with a more detailed
explanation in the project documentation

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