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

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

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>

More information about the Python-Dev mailing list