[Python-Dev] Status of packaging in 3.3

[PJ Eby]

On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn <
d.s.seljebotn at astro.uio.no> wrote:

> On 06/22/2012 10:40 AM, Paul Moore wrote:
>
>> On 22 June 2012 06:05, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>
>>> distutils really only plays at the SRPM level - there is no defined OS
>>> neutral RPM equivalent. That's why I brought up the bdist_simple
>>> discussion earlier in the thread - if we can agree on a standard
>>> bdist_simple format, then we can more cleanly decouple the "build"
>>> step from the "install" step.
>>>
>>
>> That was essentially the key insight I was trying to communicate in my
>> "think about the end users" comment. Thanks, Nick!
>>
>
> The subtlety here is that there's no way to know before building the
> package what files should be installed. (For simple extensions, and perhaps
> documentation, you could get away with ad-hoc rules or special support for
> Sphinx and what-not, but there's no general solution that works in all
> cases.)
>
> What Bento does is have one metadata file for the source-package, and
> another metadata file (manifest) for the built-package. The latter is
> normally generated by the build process (but follows a standard
> nevertheless). Then that manifest is used for installation (through several
> available methods).
>

This is the right thing to do, IMO.

Also, I think rather than bikeshedding the One Serialization To Rule Them
All, it should only be the *built* manifest that is standardized for tool
consumption, and leave source descriptions to end-user tools.  setup.cfg,
bento.info, or whatever...  that part should NOT be the first thing
designed, and should not be the part that's frozen in a spec, since it
otherwise locks out the ability to enhance that format.

There's also been a huge amount of previous discussion regarding setup.cfg,
which anyone proposing to alter it should probably read.  setup.cfg allows
hooks to external systems, so IIUC,  you should be able to write a
setup.cfg file that contains little besides your publication metadata
(name, version, dependencies) and a hook to invoke whatever build tools you
want, as long as you're willing to write a Python hook.

This means that bikeshedding the build process is totally beside the
point.  If people want to use distutils, bento, SCons, ...  it really
doesn't matter, as long as they're willing to write a hook.  This is a
killer app for "packaging", as it frees up the stdlib from having to do
every bloody thing itself and create One Build Process To Rule Them All.

I didn't invent setup.cfg or write the "packaging" code, but I support this
design approach wholeheartedly.  I have only the smallest of quibbles and
questions with it, but they aren't showstoppers.  I've already had some
discussion about these points on Distutils-SIG, and I think that should be
continued.

If there *is* to be any major discussion about switching directions in
packaging, the place to start should be *use cases* rather than file
formats.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120622/ca2fb129/attachment.html>