[Python-Dev] splitting out bdist_* (was: interminable 'setuptools' thread)
glyph at divmod.com
glyph at divmod.com
Fri Mar 27 21:49:53 CET 2009
On 07:59 pm, fdrake at acm.org wrote:
>I'm actually in favor of removing the bdist_* from the standard
>library, and allowing 3rd-party tools to implement whatever they need
>for the distros. But I don't think what you're presenting there
>supports it.
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
This has been a problem for me, personally, since debian has made
various ad-hoc change to Twisted or Twisted-based packages to break our
plugin system, since the distutils metadata has been insufficient for
their purposes. If the deb-generating stuff were in a separate project
with a faster release cycle that were easier to contribute packages to,
perhaps debian packagers could be convinced to contribute their build-
hacks there (and bdist_deb could invoke debhelper, or vice-versa).
It would be great if someone could volunteer to maintain this stuff
independently, put it in a Launchpad project or something. IMHO it
would be better for the community at large if this were spun as
"increasing the release speed" of the bdist_* family, rather than
"removing", which seems to me like it would generate another teacup-
tempest on the blogowebs. Of course I'm not volunteering, but I will be
best friends forever with whoever does this PR/maintenance :).
Given that py2exe and py2app (which includes "bdist_mpkg") are both
based on distutils, it seems like we're on the way to independent
maintenance anyway. Perhaps bdist_wininst/_msi could be donated to the
py2exe project if they would be willing to maintain it, and the new
project for _deb and _rpm could be called "py2packman" or something.
More information about the Python-Dev
mailing list