[Distutils] status check on PEP 517

Nathaniel Smith njs at pobox.com
Fri Jul 28 19:07:03 EDT 2017


On Fri, Jul 28, 2017 at 1:58 PM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> I think this was actually a question that someone (Nathaniel?) brought up:
> is the project source directory on sys.path when the backend is loaded? I
> would lean yes, so that it's possible to have a custom backend in the
> project tree, but I think whoever brought it up before was leaning no.

You're probably thinking of
  https://github.com/njsmith/peps/blob/90f7adc130cbae741b1abd3a9ad407ba6731ea9f/pep-0517.txt#L976-L987

As noted there, my suggestion would be that we don't put the project
directory on sys.path by default, but that we do provide an explicit
configuration key that lets projects name a directory in the project
tree that should be prepended to sys.path. So example:

[build-system]
python-path = ["."]
build-backend = "my_custom_backend"    # refers to
my_custom_backend.py in the project root

# - or -

[build-system]
python-path = ["tools"]
build-backend = "my_custom_backend"    # refers to tools/my_custom_backend.py

Rationale:

- Having the project source directory on sys.path when you don't
expect it is confusing and error-prone
- If you do want it on sys.path then it's easy to add a line to
pyproject.toml, explicit > implicit
- I think it's an anti-pattern how every piece of tooling wants to
claim part of the top-level directory (.travis.yml, appveyor.yml,
.readthedocs.yml, CONTRIBUTING.yml, ...) -- pyproject.toml has to go
there because it's the root where all our tooling starts from, but we
should support projects that want to tuck away the rest of their
tooling into some subdirectory :-)

Given how much trouble we're having with PEP 517 already, it might
make more sense to have PEP 517 just mandate that the directory not be
on sys.path, and make a little follow-up PEP just for python-path.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org


More information about the Distutils-SIG mailing list