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

[Nick Coghlan]

On Sun, Dec 9, 2012 at 8:41 AM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/08/2012 05:06 AM, Nick Coghlan wrote:
>
> > 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.
>
> Building such systems is *too hard* to deletgate to the maintainers of
> every Python distribution registered on the Cheeseshop:  there is too
> much policy involved for the ha'penn'orth of mechanism we are discussing
> here (decentralized inter-project metadata) to support.
>
> Such metadata *cannot* be useful in the general sense, but only in the
> context of a "curated" collection of packages, where the *curator* (not
> the upstream package authors) makes the choices.
>

The authors of major projects are often in a good position to know when
they conflict with other high profile projects and thus can't be used
reliably in the same system. Now, *most* of the time, if there's a genuine
conflict between two Python packages, it's going to be at install time -
two projects attempting to install the same file obviously can't coexist on
a single system (distribute and setuptools, for example, conflict at this
level - they both want to own the "setuptools" and "easy_install" names).
However, Python has plenty of other global state too (the codec registry,
the import system, monkeypatching), and there is potential for conflict
over underlying OS level resources.

So let's look at the case of collections of Python packages that *are*
curated. Maybe I'm a Linux distro packager, looking to automate the
conversion to distro packages. Maybe I'm a toolsmith for a large
corporation trying to build a curated set of packages for internal use
(clearly indicating to my internal users which ones don't play nicely with
each other and thus shouldn't be used together in the same project).

Regardless of the reason, I'm the curator for a collection of Python
packages. How shall I express the conflicts I have identified? Shall I go
invent my own metadata system? Shall I be forced to choose a particular
platform-specific dependency management system? How shall upstream authors
communicate to *me* the conflicts that they're already aware of?

Or, hey, there's this nice shiny cross-platform dependency management
system *right here*. Maybe they'll be nice enough to consider handling *my*
use case as well, even if it's a use case *they* don't care about.

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/7c8b687a/attachment.html>