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

Nick Coghlan ncoghlan at gmail.com
Sat Dec 8 11:06:21 CET 2012

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.

The beneficiary of these notifications is the aggregator attempting to build a systematically coherent system, rather than one with latent incompatibilities waiting to bite them at run time. It doesn't matter if "A conflicts with B" or "B conflicts with A", you cannot have a system with both of them installed that will be supported by the developers of both A and B.

Now, this beneficiary may be the packagers for a Linux distribution, but it may also be a larger Python distribution (ActiveState, EPD, etc), a web application developer, a desktop application developer, a system integrator for a large-scale distributed system, or anyone else that combines and deploys an integrated set of packages (even those a developer installs on their personal workstation).

It's up to the user to decide who they want to believe. Now, it may be that, for a given use case, the end user doesn't actually care about the potential conflict (e.g. they've done their own research and determined that the conflicting behaviour doesn't affect their system) - that's then a design decision in the installation tools as to whether or not they want to make it easy for users to override the metadata. In the Linux distro case, the installer and most of the metadata are largely provided by the same people, so yum/rpm/etc generally don't make it easy to install conflicting packages. Python installers are in a different situation though, so forced installs are likely to be an expected feature (in fact, I expect the more likely outcome given the status quo is that the default behaviour will be a warning at installation time with an option to request enforcement of "no conflicts").

Building integrated systems is hard. Pretending projects can't conflict just because they're both written in Python isn't sensible, and neither is it sensible to avoid warning users about the the potential for latent defects when particular packages are used in combination.

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/20121208/912657bb/attachment.html>

More information about the Python-Dev mailing list