[Distutils] Builders vs Installers
Erik Bray
erik.m.bray at gmail.com
Tue Mar 26 21:58:35 CET 2013
On Tue, Mar 26, 2013 at 2:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 26, 2013 at 3:15 PM, PJ Eby <pje at telecommunity.com> wrote:
>> More specifically, I was hoping to move the discussion forward on
>> nailing down some of the details that still need specifying in a PEP
>> somewhere, to finish out what the "new world" of packaging will look
>> like.
>
> I'm deliberately trying to postpone some of those decisions - one of
> the reasons distutils2 foundered is because it tried to solve
> everything at once, and that's just too big a topic.
>
> So, *right now*, my focus is on making it possible to systematically
> decouple building from installing, so that running "setup.py install"
> on a production system becomes as bizarre an idea as running "make
> install".
>
> As we move further back in the tool chain, I want to follow the lead
> of the most widely deployed package management systems (i.e. Debian
> control files and RPM SPEC files) and provide appropriate configurable
> hooks for *invoking* archivers and builders, allowing developers to
> choose their own tools, so long as those tools correctly emit
> standardised formats understood by the rest of the Python packaging
> ecosystem.
Right--what we really need here is something akin to the debian/rules
file, only not a shell script :) I like the hook idea. It's the "so
long as those tools correctly emit standardised formats" that's the
problem.
> In the near term, however, these hooks will still be based on setup.py
> (specifically setuptools rather than raw distutils, so we can update
> older versions of Python).
That pretty much eases the concerns I brought up in the "backwards
compat" thread.
>> But, if we support "either you have a setup.cfg specifying your
>> archiver, or a PKG-INFO so an archiver isn't needed", then that would
>> probably cover all the bases, actually.
>
> Yeah, you're probably right that we will need to support something
> else in addition to the PKG-INFO file. A PKG-INFO.in could work,
> though, rather than a completely independent format like setup.cfg.
> That way we could easily separate a source checkout/tarball (with
> PKG-INFO.in) from an sdist (with PKG-INFO) from a wheel (with a named
> .dist-info directory).
I'm partly in favor of just saying, "there should be a PKG-INFO in
your version control to be considered a valid python distribution".
Intermediate formats like a setup.cfg or Nick's JSON format seem kind
of unnecessary to me--why have two different formats to describe the
same thing? In cases where the metadata needs to be mutated
somehow--such as attaching revision numbers to the version--some sort
of PKG-INFO.in like you suggest would be great. But I don't see why it
should have a different format from PKG-INFO itself. I'd think it
would just be a superset of the metadata format but with support for
hooks. Basically akin to what d2to1 does with setup.cfg, but without
the unnecessarily different-looking intermediate format
(I do agree that a JSON format would allow a much greater degree of
expression and flexibility, but I'm not entirely sure how I feel about
having one file format that generates an entirely different file
format).
> (For consistency, we may want to rename PKG-INFO to DIST-INFO in sdist
> 2.0, though)
+1
Thanks,
Erik
More information about the Distutils-SIG
mailing list