[Python-Dev] "setuptools has divided the Python community"
eric at trueblade.com
Fri Mar 27 14:47:32 CET 2009
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.
More information about the Python-Dev