Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
2009/3/27 Guido van Rossum <gu...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
