Sort of riffing on this idea, I cannot seem to find a specification for what a Python

package actually is. Maybe the first effort should focus on this instead of arguing one

implementation or another.  

As a packager:

    I should not (in general) care what tool (pip, pysetup, easy_install, buildout, whatever) is used

    to install my package, My package should just describe what to do to install itself.

As a end user:

   I should not (in general) care what tool was used to create a package (setuptools, bento, distutils,

   whatever). My tool of choice should look at the package and preform the operations that the package

   says are needed for install.

Ideally the package could have some basic primitives that are enough to tell the package installer

tool what to do to install it, These primitives should be enough to cover the common cases (pure python

modules at the very least, maybe additionally some C modules). Now as others have remarked it would

be insane to attempt to do this in every case as it would involve writing a build system that is more

advanced than anything else existing, so a required primitive would be something that allows calling out

to a specific package decided build system (waf, make, whatever) to handle the build configuration.

The eventual end goal here being to make a package from something that varies from implementation

to implementation to a standardized format that any number of tools can build on top of. It would likely

include some things defining where metadata MUST be defined.

For instance, if metadata in setuptools was "compiled" down to static file, and easy_install, pip et;al

used that static file to install from instead of executing setup.py, then the end user would not have

required setup tools installed and instead any number of tools could have been created that utilized

that data.