On 27 October 2015 at 13:07, Ionel Cristian Mărieș
On Tue, Oct 27, 2015 at 1:23 AM, Robert Collins
wrote: wheel: flit wheel -d $ OUTPUT_DIR
What's expected to happen if there are multiple files produced in $OUTPUT_DIR? Is it an error?
https://github.com/pypa/pip/blob/develop/pip/wheel.py#L665 is the calling function in pip today. It picks a single output, so if a wheel build generates multiple outputs, the results will be nondeterministic. Don't do that :).
Also, doesn't this pep overlap with PEP 426? Shouldn't these ideas be incorporated there? It seems that only the command metadata is missing from PEP 426.
It does. I believe Nick wants to see PEP-426 broken up into small bits. The meta build system described in PEP 426 is aspirational and not reflective of what pip *actually does today*. The intent I have with this PEP is to have something that preserves the current behaviour while adding the abstraction - but there is no PEP that describes the current markers-inclusive metadata on disk (345 misses setup-requires and markers). So we may need a PEP to just bless the metadata from 426, without any of the aspirational stuff.
Another thing, I've noticed there's a "develop" command in this draft. I think this is confusing, I'd expect it to be a "install" command (and that's what it is now in setuptools). It should be renamed to something more clear, like "inplace-build" and leave the installing to pip.
The current thing pip calls - and all existing released pips is
'setup.py develop'. I agree that doing an in place build and having
pip do the install into an environment would make sense, but it makes
this more aspirational. And the value here is that this is doable
*now* without e.g. an additional PEP to describe how 'develop' mode in
pip and related tools should behave and interoperate.
We can rev this in schema version 2. There's no prose in the PEP about
how that should work, so I'll add that now.
-Rob
--
Robert Collins