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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
