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

[Nick Coghlan]

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>