[Distutils] status check on PEP 517

[Paul Moore]

On 29 July 2017 at 00:07, Nathaniel Smith <njs at pobox.com> wrote:
> 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:

Feels like YAGNI to me.

> - Having the project source directory on sys.path when you don't
> expect it is confusing and error-prone

Hmm, possibly, but I think in general people will expect it - Python
scripts in general and setup.py in particular work that way.

> - 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 :-)

It leads to a certain level of clutter certainly, but it's also
reasonably natural because the project root is the only location tools
can guarantee exists, and you have to start somewhere when finding
your config.

> 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.

Or we just document that sys.path will contain the project root, and
keep it simple but flexible. A follow-up PEP could add a
pyproject.toml setting that *overrides* this default at a later date,
if the need was found compelling enough.

+1 from me on just adding the project root to sys.path.

Paul