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.