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