<p dir="ltr"><br>
On Oct 13, 2015 6:01 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> On 14 October 2015 at 05:09, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> > Hi all,<br>
> ><br>
> > I was going to send around a summary from this meeting, but I seem to have<br>
> > come down with the flu last night. So if someone else wants to do it while<br>
> > it's fresh in our minds, that'd be great, or else I'll try to get to it next<br>
> > week or so.<br>
> ><br>
> > Cheers,<br>
> > -n<br>
> ><br>
> > On Oct 12, 2015 11:01 AM, "Nathaniel Smith" <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> >><br>
> >> Hangouts URL:<br>
> >>   <a href="https://hangouts.google.com/call/fzzbnwpdujlkhtcv6lmcopnqj4a">https://hangouts.google.com/call/fzzbnwpdujlkhtcv6lmcopnqj4a</a><br>
> >><br>
> >> Shared document for notes:<br>
> >><br>
> >> <a href="https://docs.google.com/document/d/11MZVPaayaFD3dd1NRjcKpyzlk_1IXkgQDqtkxkXuoNk/edit?usp=sharing">https://docs.google.com/document/d/11MZVPaayaFD3dd1NRjcKpyzlk_1IXkgQDqtkxkXuoNk/edit?usp=sharing</a><br>
><br>
> So that ^ is worth a read for any interested party.<br>
><br>
> The summary:<br>
><br>
> We agreed on the following design constraints(MUSTS):<br>
><br>
> * Graceful forward compat (old pip either can install, or fails<br>
> cleanly, on new VCS and sdists, pypi can be changed )<br>
> * Backwards compat (new pip can install both old and new VCS/sdists,<br>
> new pypi can handle old and new sdists)<br>
> * Setup-requires static to the point the build system can be installed by pip<br>
> * Setup-requirements need to be isolated: must be able to use<br>
> different incompatible versions of the same setup-requirement during<br>
> one install run.<br>
> * Describing how to use the build system has to be user friendly.<br>
> [e.g. json configs are out]</p>
<p dir="ltr">(.cfg | .yml) > JSONLD</p>
<p dir="ltr">Should these build settings all be included in e.g. PEP 426 + JSONLD metadata.jsonld?<br>
- for backward compat, there would then be both metadata.json and metadata.jsonld (because of normative JSONLD form and PEP 426+)</p>
<p dir="ltr">.cfg (ConfigParse): (section, key, value)</p>
<p dir="ltr">.yml (YAML lib xyz): easily maps to JSONLD (which always maps to an RDF triple graph (of linked typed packages with attributes, generated from [...]))</p>
<p dir="ltr">><br>
> And the following design goals(SHOULDs):<br>
><br>
> * Be able to use things like flit cleanly within pip without needing a<br>
> setup.py in-tree.<br>
> * Long term - reduce variation in code paths<br>
> * Long term - reduce amount of dynamism? in install pipeline?</p>
<p dir="ltr">* OS Packaging compat (--prefix)<br>
* Conda solves for this. (static files with package-level checksums)</p>
<p dir="ltr">>   * We may never be able to remove it entirely, but being able to not<br>
> run egg-info in the common case should be achievable<br>
>   * Things that have reason to change (deps) are more reasonable to be<br>
> dynamic (even with PEP-426 markers there are exceptions)<br>
>   * project description, version etc in sdist have no reason to be dynamic<br>
> * Files in VCS should not need to be different in sdist - ever<br>
><br>
><br>
> We had broad agreement on the basic design:<br>
> * There will be a file that describes how to install the build tool,<br>
> and how pip or other systems should invoke it<br>
> * It will be minimal: this file is strictly additive to the system, no<br>
> overlap with existing things (even setup-requires - because<br>
> setup-requires presumes the buildtool (setuptools) is already<br>
> installed)<br>
><br>
> I *think* we had broad agreement that its not desirable, overall, to<br>
> try and skip steps like metadata generation - because with a resolver<br>
> we'd end up potentially doing things like building dozens of versions<br>
> of scipy just to extract metadata about dependencies.<br>
><br>
> I like the term 'bootstrap-requires' -because we're bootstrapping the<br>
> ability to use the build tool.<br>
><br>
> The build tool interface needs to be sufficient that one could write a<br>
> shim to existing setuptools in it. Previous posts have described what<br>
> that might look like, but to reprise my sketch it had the following<br>
> entries<br>
> schema: #was version<br>
> egg-info:<br>
> dist-info:<br>
> wheel:<br>
> develop:<br>
> install:<br>
> provided-by:<br>
><br>
> We have a design decision to make.<br>
><br>
> We could make bootstrap-requires be a superset of setup-requires. That<br>
> is, projects should put anything that is functionally a setup-requires<br>
> thing into bootstrap-requires. This had the ad-hoc effect of dictating<br>
> to setuptools how static setup-requires would be expressed. I don't<br>
> tlike that.<br>
><br>
> Alternatively we can make the interface permit querying for things to<br>
> install before running any of the other things in the build system<br>
> interface: e.g. one way would be<br>
><br>
> build-requires:<br>
>   # command to query for package specific build dependencies<br>
>   # returns a PEP-426 JSON file, only the keys<br>
> <a href="https://www.python.org/dev/peps/pep-0426/#metadata-version">https://www.python.org/dev/peps/pep-0426/#metadata-version</a> and<br>
> "build_requires" are consulted.<br>
><br>
> Alternatives here include:<br>
>  - just generating {dist.egg}-info twice - once to get setup_requires,<br>
> once to get everything once thats resolved<br>
>  - drop dist-info and egg-info and use PEP-426 for those calls as well<br>
>  - don't use pep-426 at all, just use requires.txt format which is<br>
> already well established<br>
>  - Use a pep-345 file<br>
><br>
> I think pep-426 is ok since we're already using it within wheels<br>
> (metadata.json). I'm a little nervous about dropping<br>
> egg-info/dist-info - but hell, lets try it (since its common to have a<br>
> proof of concept before accepting peps, we'll know it works for<br>
> setuptools since that should be in the proof of concept). That would<br>
> give a build tool interface of:<br>
><br>
> schema: #was version<br>
> build-requires: # command to get a pep-426 json blob on stdout with<br>
> build_requires populated<br>
> dist-info: # command to get a pep-426 json blob on stdout with<br>
> everything populated<br>
> wheel: # build a wheel<br>
> develop: # do a develop install<br>
> install: # do a direct install<br>
> provided-by: # allows caching the build tool interface<br>
><br>
> We need to define the exact environment that the build tool will be<br>
> run in: will it inherit already installed things from the install<br>
> target? Will it be isolated or hermetic? Being able to fix things at a<br>
> distance is important - and remembering we have a lot of legacy paths,<br>
> that means a greenfield approach isn't very viable.<br>
><br>
> Separately we need to define how-and-when dist-info will be called in<br>
> the case of sdists which have valid static metadata. Thats<br>
> sufficiently different we think it should be a separate PEP.<br>
><br>
> Go forward:<br>
><br>
> Nathaniel to write two PEPs:<br>
>  * bootstrap-requirements and build system interface - enables<br>
> multiple build systems<br>
>  * usable static metadata in sdists - allow the common case to do less<br>
> work by ensuring valid metadata in sdists<br>
><br>
> -Rob<br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>