<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
> 4) Although using a process interface is not necessarily a problem, I don't<br>
> agree with your point on why a python interface would be unworkable.  You're<br>
> assuming that pip would try to import all the build tools (for every<br>
> dependency it's processing) in the master process.  An alternative could be<br>
> that pip would have it's own tool (that runs as a subprocess in an isolated<br>
> env) that knows how to load and work with python build interfaces.   You<br>
> could argue that a python api is  an advantage, because build tools aren't<br>
<br>
</span>That would mean that pip has to have the same exact version of it embedded<br>
in the environment that build tools will be run in, which it doesn't have today.<br></blockquote><div><br></div><div>sorry, I can't make clear sense of your sentence here.  :  )  </div><div><br></div><div>I'll just explain my point again.  </div><div><br></div><div>pip doesn't necessarily have to "interact with many different versions of the same build tool during a single invocation" if for example it's subprocessing the interactions to some "pip-build" tool that handles the imports and use of the python API.  I.e. pips calls some "pip-build" too (per build), which does the import, not pip itself.</div><div><br></div><div>and again, it's not about arguing for this idea, but just that your "in-process APIs are harder" argument doesn't decide the matter.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
</span>I see no problem with evolving them in lockstep, </blockquote><div><br></div><div>it's unnecessarily complex IMO.  if they're really in lockstep, then they're one thing it seems to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'd rather avoid the chance for a bug where something tries to parse a<br>
v2 schema build<br>
description with a v1 schema parser. </blockquote><div><br></div><div>but it won't happen?  the pypa.yaml schema version would determine the parser version that's used. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> 7) it's unclear when pip get's to run "dist-info" and when the result might<br>
> be different.   For example, we've discussed that run time dependencies may<br>
> get clarifed *after* the build process.... so this command might produce<br>
> different results at different times?<br>
<br>
</span>Pip would run dist-info when determining the install-requires and<br>
extras for the package. </blockquote><div><br></div><div>you're not addressing the point about how the act of building can create new run time dependencies, per the whole long discussion with Nathaniel  recently  (his draft deals with this matter explicitly)</div><div><br></div><div>--Marcus</div><div><br></div></div></div></div>