[Python-Dev] Status of packaging in 3.3 (original) (raw)

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 bdistsimple discussion earlier in the thread - if we can agree on a standard bdistsimple 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