[Python-Dev] splitting out bdist_* (was: interminable 'setuptools' thread)

[M.-A. Lemburg]

On 2009-03-27 21:49, glyph at divmod.com wrote:
> 
> 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.

Do you really think that splitting up the distutils package is
going to create a better user experience ?

What would benefit the bdist_* commands is externalized maintenance,
ie. have more frequent releases on PyPI, but still ship the
most up-to-date versions with core distutils in each new Python
release.

BTW: py2exe and py2app solve a different set of problems than distutils
is trying to solve. They are about packaging complete applications,
not individual packages, so I don't see how they relate to the
bdist_* commands. But perhaps I'm missing some context.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 27 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2009-03-19: Released mxODBC.Connect 1.0.1      http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/