On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn <d.s.seljebotn@astro.uio.no> wrote:
On 06/22/2012 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlan<ncoghlan@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.