On Fri, Jun 22, 2012 at 9:11 PM, PJ Eby <p...@telecommunity.com> wrote: > On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> >> On 06/22/2012 10:40 AM, Paul Moore wrote: >>> >>> On 22 June 2012 06:05, Nick Coghlan<ncogh...@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 _______________________________________________ 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