[Python-Dev] "setuptools has divided the Python community"

[Eric Smith]

Olemis Lang wrote:
> On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> 2009/3/27 Guido van Rossum <guido at python.org>:
>>> - keep distutils, but start deprecating certain higher-level
>>> functionality in it (e.g. bdist_rpm)
>>> - don't try to provide higher-level functionality in the stdlib, but
>>> instead let third party tools built on top of these core APIs compete
>> Please don't move bdist_wininst out of the core, though!
>>
>> I'd argue that Windows is a special case, as many Windows users don't
>> have the ability to build their own extensions,
> 
> Hmmmm ... what about devs (me?) trying to build installers for
> multiple platforms being in a single OS (let's say Ubuntu ...) ? IMO
> in this case where policies are unique for a particular OS-flavour
> (deb, rpms, and so on ...) ... there should be a single way to package
> your app and to conform to the standards agreed by distros (e.g.
> Debian) and maintainers ... isnt it enough std to be in stdlib ? I'd
> really like to have those (... at least the most influential systems
> ... rpm, debs, and maybe two or three more that I'm missing here ...)

The idea is to make the metadata extensible, so that for example Debian 
specific information can be put in the same config file that contains 
the "normal" metadata. I guess it would even be possible for this 
additional metadata to be in a separate config file. That way if someone 
downstream from me says "I can automatically build a .deb file if you'd 
just include this metadata", I could easily do that. I don't think it's 
reasonable that a package builder could possibly know all of the config 
information. To some extent, this is all currently possible with 
setup.cfg, and I do that myself.

I'm also not convinced there will be a single "bdist_rpm" (or whatever) 
replacement. It's entirely possible that different people would want to 
build different flavors of rpm's from the same metadata. Someone might 
be a real FHS devotee, and someone else might have practical reasons to 
not follow it.

> Indeed I'd like to know the arguments behind «deprecating certain
> higher-level functionality in it (e.g. bdist_rpm)» BTW ... perhaps
> they'r self-explanatory and therefore I should not be asking this at
> all ... :P

I believe it's largely a refactoring. It's just too complicated and 
difficult to extend the way it is now.

Eric.