On 2 August 2017 at 15:11, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Aug 1, 2017 at 9:31 AM, Thomas Kluyver <thomas@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@gmail.com | Brisbane, Australia