[Distutils] status check on PEP 517

[Nick Coghlan]

On 2 August 2017 at 15:11, Nathaniel Smith <njs at pobox.com> wrote:
> On Tue, Aug 1, 2017 at 9:31 AM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>> Are we content to say that sys.path includes the source directory where
>> the hook is run? Shall I prepare a PR against the PEP for that?
>
> It doesn't matter whether sys.path includes the source directory when
> the hook is run. At that point the hook can manipulate sys.path
> however it likes, just like setup.py can. What matters is whether
> sys.path includes the source directory before the backend is imported.
>
> And I think that even if we keep the source directory in sys.path,
> then there's at least a further piece of refinement needed. The
> obvious mechanism for adding the source directory to sys.path is by
> setting PYTHONPATH before invoking the sub-python that runs the build
> backend.

I wouldn't say that, as the two most clearly side effect free ways of
putting the source directory on sys.path are:

1. make it the current working directory for a "python -m" or "python
-c" invocation, so that the current directory gets injected as
sys.path[0] by the interpreter. After all, it's already a requirement
in the PEP that the current working directory be the directory
containing pyproject.toml, so this approach handles that as well.
2. run a backend script directly (so it's the script directory that
gets implicitly added to sys.path by the interpreter), and then inject
the current working directory as sys.path[0] before importing the
nominated backend

If a frontend decides to go messing about with PYTHONPATH instead of
doing either of those, then that's on them (and after it breaks
horribly, they'll hopefully realise the error of their ways and switch
to one of the other more reliable approaches).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia