2009/7/9 Eric Smith <e...@trueblade.com>: > 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.
+1. Now who's going to design & write it? > 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. There still needs to be some sort of package build system. I do *not* want to see a situation where users can't easily build their own packages. Not all systems have all Python packages packaged up by "official" system packagers... Paul _______________________________________________ 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