[Python-Dev] PEP 376 - Open questions

Eric Smith eric at trueblade.com
Thu Jul 9 05:20:59 CEST 2009


P.J. Eby wrote:
>> ISTM that the problem that it solves is uninstall in the absence of
>> the original installer.
> 
> Or uninstall where the installer is "setup.py install", actually.

I think we need to move away from "setup.py install". It's the 
antithesis of static metadata. setup.py needs to go away.

If we have a static metadata file called, say "setup.info", then I'd 
like to see:
"bdist_rpm setup.info" produce a .rpm
"bdist_msi setup.info" produce a .msi
"bdist_deb setup.info" produce a .deb
"bdist_egg setup.info" produce a .egg
and so on.

There might be a library (and I call dibs on the name "distlib" :) that 
provides support routines to parse setup.info, but there's no framework 
involved. And no need for a plugin system.

There might be support routines used to build setup.info. For those who 
think it's reasonable that the list of source files comes from your 
version control system, build a small command that produces setup.info 
from your vcs. If you need the version number to come from some other 
source, write a small command that reads that and sticks it into a 
setup.info. But the source distribution would be defined by a (possibly 
generated) setup.info.

The metadata in setup.info would be extensible. If setup.info contains 
information that's needed to build a .rpm that's not needed for a .deb, 
then that's fine. We can define the minimum information needed and an 
extension mechanism. As time goes by, some of the extensions might 
become standardized.

Then for each binary format, there's an installer (or more than one!), 
and it might handle dependency detection and automatic fetching, or it 
might not. Some of these exist (apt-get, yum, msi), some might need some 
tweaking (setuptools, pip) and others might need to be written from 
scratch. But the installer, its database of what it has installed, and 
how it handles uninstalls (if it does) is really not the issue.

It's the conflation of "build a package" with "install a package" that 
distutils and setuptools has given us (via setup.py) that leads to us 
never making progress. Let's just focus on "describe a package" and let 
the packagers handle "build a package" and let the installers handle 
"install and uninstall a package". Then the packagers (and their 
associated installers) can evolve independently of each other.


More information about the Python-Dev mailing list