On 5 July 2017 at 10:45, Nathaniel Smith <n...@pobox.com> wrote:
> I already responded to several of the overall points elsewhere in the
> thread, but a few specific points:
>
> On Mon, Jul 3, 2017 at 7:03 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> I want prepare_wheel_metadata there as a straightforward way for
>> backends to expose the equivalent of "setup.py egg_info". Losing that
>> would be a significant regression relative to the status quo, since
>> pip relies on it during the dependency resolution process
>
> AFAIK this is a new argument that hasn't been made previously in any
> of the discussions here. Is it a real problem that we've all missed?
> This is important, because if pip really needs prepare_wheel_metadata
> right now, then that's an argument that it needs to be a *mandatory*
> hook, which is not the case in any version of PEP 517.
The hook is optional in order to better accommodate backends like
flit, which don't support binary extensions, so wheel creation is
inherently fast.
By contrast, a backend like setuptools or enscons definitely *should*
implement this hook, since actually building the wheel may end up
compiling arbitrary amounts of C/C++/Go/Rust/FORTRAN/etc, and hence
take ages.
>> To tighten that requirement up even further: if the backend's
>> capabilities can't be accurately determined using
>> "inspect.getattr_static", then the backend is not compliant with the
>> spec. The build frontend/backend API is not a space where we want
>> people to try to be clever - we want them to be completely dull and
>> boring and use the most mundane code they can possibly come up with.
>
> This does sound like a nice idea, but I mean, look at what people do
> to distutils... I don't think there's much value in putting in
> Strongly Worded Prohibitions that people will just ignore.
>
> Also I don't think getattr_static is what you mean -- e.g. flit might
> well write something like:
>
> # flit/backend.py
> if os.path.exists(".git"):
> def build_sdist(config_settings):
> ...
>
> and that's totally getattr_static compliant.
I'd technically be OK with backends taking that approach - the minimal
design guideline is that the exposed backend API should be consistent
for a given working directory and execution platform, and import time
games are able to comply with that fairly readily.
Of course, the *easiest* way to respect the consistency principle is
to just not play any conditional availability games at all, and
instead put any relevant environmental checks inside the
"get_requires_for_build_*" call.
>>> - Add a TODO to decide how to handle backends that don't want to have
>>> multiple hooks called from the same process, including some
>>> discussion of the options.
[snip]
> If you read the text, I pretty much came to the same conclusion :-). I
> wanted to flag it as TODO though b/c AFAICT there hasn't been any
> discussion of the trade-offs on the list, so the text I wrote is
> raising new topics.
>
> That said, if you have prepare_build_metadata and prepare_build_files,
> then those *also* raise the issue of whether you really want to have
> to spawn a new process. They ~double the number of process spawns,
> which is significant overhead on Windows.
>
> I suspect the right answer in any case is to default to running each
> hook in a new process, and either now or later add a flag the backend
> can provide to say that it's happy to run multiple hooks in the same
> process. (Adding this later is totally backwards compatible if the
> default is separate processes.)
Aye, that reasoning sounds solid to me.
I'm not going to make the revised PR today after all (since I want to
give folks a chance to read and respond to my latest posts to this
thread first), so how do you want to proceed with the next step?
I see two main options:
- you work up your changes into a PR against PEP 517, submit that to
the PEPs repo, and I merge it after Thomas signs off on the updates
- same basic idea, but I create the PR based on your current draft
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
