Hi,

On Mon, Aug 21, 2017 at 5:39 PM, xoviat <xoviat@gmail.com> wrote:

This statement comes from something that Donald said:

> The unvendoring means that setuptools and the project code are now competing over who gets to define what an acceptable version is for these libraries to be installed with.

As if this isn't going to be true for any other build system, and setuptools won't at all be in any way special in a PEP 517 world. So you are always going to have complaints about "well build system X required a newer version but my project requires an older version" when the real problem is that people are requiring an older version/ projects do not have a stable API.

It seems to me that this is one of those things where the solution is staring us in the face.

If PEP 517 simply clarifies that, since the build steps should be run with either the original checkout or a cleaned-up sdist as the current directory, this directory will be naturally the first on `sys.path` (and shouldn't be removed), so build backends can rely on its presence there.

In `setuptools` case, if it wants to depend at build time (i.e. `setup_requires`) on other packages that depend on `setuptools', it can't specify them as `[build-system]requires`, but it's free to specify them as `get_requires_for_build*()`, since `setuptools` itself will be on `sys.path`.

`get_requires_for_build*()` just needs to arrange for the source distribution directory to contain enough of whatever metadata format is needed to be recognized as an installed dist to be depended upon while being on sys.path.

As mentioned, the real trouble begins when `setuptools` wants to depend at runtime (`install_requires`) on other packages since incompatible versions of these packages could spell trouble to packages that depend on setuptools AND on these incompatible versions.

If setuptools doesn't want to "hard vendor" these dependencies (i.e. keep a copy of them in its own repository), one possible solution is for `setuptools` to vendor these dependencies at build time:

- make them build dependencies as above

- locate where they were installed by their `.dist-info/RECORD`, or failing that, their `.__file__` module attribute.

- copy them over to it's own `setuptools._vendor` package, patching them if necessary.

An enviroment (e.g. upstream distributor) wanting to bootstrap everything from source would then need to make sure setuptools and all its dependencies are installed in the same python environment in "development mode" (/me handwaves the fact that this operation is not strictly defined). A frontend could be written to do just that.

Regards,

Leo