[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