2009/7/9 Eric Smith <eric at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4