[Python-Dev] Status of packaging in 3.3

David Cournapeau cournape at gmail.com
Fri Jun 22 22:35:09 CEST 2012


On Fri, Jun 22, 2012 at 9:11 PM, PJ Eby <pje at telecommunity.com> wrote:
> 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.

agreed. I may not have been very clear before, but the bento.info
format is really peripherical to what bento is about (it just happens
that  what would become bento was started as a 2 hours proof of
concept for another packaging discussion 3 years ago :) ).

As for the build manifest, I have a few, very out-dated notes there:

http://cournape.github.com/Bento/html/hacking.html#build-manifest-and-building-installers

I will try to update them this WE. I do have code to install, produce
eggs, msi, .exe and .mpkg from this format. The API is kind of
crappy/inconsistent, but the features are there, and there are even
some tests around it. I don't think it would be very difficult to hack
distutils2 to produce this build manifest.

David


More information about the Python-Dev mailing list