<p dir="ltr"><br>
On 13 Feb 2013 02:50, "PJ Eby" <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
><br>
> On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren <<a href="mailto:ronaldoussoren@mac.com">ronaldoussoren@mac.com</a>> wrote:<br>
> > The hook could be one or two new header fields in the PKG-INFO<br>
> > file, with a PEP that describes those keys and how the builder is invoked and what<br>
> > it is supposed to do. Am I understanding this correctly?<br>
> ><br>
> > Something like:<br>
> ><br>
> > Extension: pepYYY-builder<br>
> > pepYYY-builder/dist: bento (>=1.1)<br>
> > pepYYY-builder/build: bento.builder:run<br>
><br>
> For simplicity's sake and decoupling/DRY, I'd say the bento project<br>
> should be the one who'd include the 'build' field specifying the entry<br>
> point.  The depending projects should only have to say they're using<br>
> bento as a builder.  That allows bento to refactor without breaking<br>
> depending projects.<br>
><br>
> If Vinay's distlib supports entry points and will be in the stdlib,<br>
> that'd be even better, since it would avoid having to create Yet<br>
> Another Module+Attribute String Parser And Dynamic Importer.  ;-)<br>
> (Not to mention documenting its spec and teaching it to people.)</p>
<p dir="ltr">Indeed, there is much hand-waving involved in my current "where would I like us to be in a couple of years?" Archiver/Builder/Installer scheme.</p>
<p dir="ltr">The immediate focus is on splitting installation out from archiving and building. Splitting archiving from building is going to require more work and isn't especially urgent - I just wanted to be clear on my current position after Marcus raised the topic.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>