Nathaniel seems to be busy with other things at the moment, so I hope he
won't mind me passing on this list of things he'd like to resolve with
the draft PEP. I'll quote his comments and put my responses inline.

> - needs some sort of NotImplemented(Error) handling specified

We've gone round return-value vs exception a few times, but I don't
think that debate is particularly heated, so it probably just needs
someone to say "this is what we're doing". I can be that someone if
needs be. But does anyone feel strongly about it?

> - The out-of-tree build example (that makes an sdist and then builds
> it) seems like exactly the kind of implementation that Donald says he
> doesn't want to see? OTOH I think Nick said he wants to see a more
> elaborated specification of out-of-tree build strategies with this
> specifically as one of them.
> - Nick has suggested that the to-be-defined NotImplemented(Error)
> handling can be used by build_wheel to indicate that it can't do
> out-of-tree builds, so maybe the frontend should try an in-tree build
> instead. I don't know how to convert this into a real spec, though --
> like in general, if I'm a frontend and I call `hook(*args, **kwargs)`
> and it says "can't do that", then how do I know what the problem is
> and what I should try instead?
> - What happens if prepare_build_metadata returns NotImplemented /
> raises NotImplementedError?
> - I don't understand how out-of-tree builds and prepare_build_metadata
> are supposed to interact.
> - Also, AFAICT the out-of-tree build feature has no motivation
> anymore. The only mentioned use case is to support incremental build
> features in automatic build pipelines like Travis, but there are a
> number of these build pipelines, and lots of existing build systems
> that support out-of-tree builds, and AFAICT no-one actually uses them
> together like this. (I think it's because most build systems'
> out-of-tree build features are designed on the assumption that there's
> a human running the show who will deal with any edge cases.)

I believe the out-of-tree build option Nathaniel is referring to is the
build_directory parameter to build_wheel(). His proposed APIs remove
that parameter, and elsewhere in his email he describes that no-one
seems to want it: everyone thinks someone else wants it.

By my understanding, the reasons for including the build_directory
parameter are:

1. Without an explicit build directory, the developers of pip are
concerned that build backends will modify the source tree and cause
issues which users report as bugs to pip.
2. A frontend-controlled build directory could be used for caching
intermediate build artifacts. This was a secondary argument after we had
the idea, and we've never really fleshed out how we expect it to work.
There's also a concern that if the first round of frontends always use
an empty tempdir, backends will end up relying on that. I think this
second argument is a weak one unless we spend the time to figure out the
details.

Do other people see the situation in a similar way? How might we move
forwards on this?

> - needs some sort of conclusion to the srcdir-on-sys.path issue.

While Nathaniel is in the minority regarding srcdir-on-sys.path, he
argues that most of us are assuming a default position without really
thinking through it, which is certainly true of me. I don't feel
strongly about this topic, but I do want to come to a conclusion. As
Nathaniel does feel strongly about it, does anyone object to either:

A. Leaving the source dir off sys.path when loading the hooks, and
making a special backend which exposes hooks from the CWD.
B. Adding another key in the TOML file to control whether hooks can be
loaded from the source dir.

I can live with either, but I prefer A, because it means fewer options
to describe in the spec.

Thomas
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig