[Distutils] status check on PEP 517

[Nick Coghlan]

On 30 July 2017 at 02:46, Nathaniel Smith <njs at pobox.com> wrote:
> Or am I worrying about a non-issue and it's fine if flit imports click from
> the source tree?

Don't worry about it too much, as the problem here isn't really any
worse than it is for normal runtime dependencies of any other project
that relies on having the current directory first in sys.path. It just
so happens that the project in question in this case is a Python
project's build system.

Due to the preference for a flat module namespace as the default,
there are plenty of ways to hit name shadowing problems in Python, and
as Donald notes, build systems have other motives to vendor their
dependencies rather than installing them normally.

Just switching the path order as has been suggested also doesn't solve
the problem, as it merely inverts the issue: having "some_name"
installed in site-packages would break source installations of
packages that expected to be able to import "some_name" from their own
root directory.

If the problem does come up in practice, then there are a number of
ways for affected projects to work around it in their project
directory structure:

1. Use a top-level "src" directory (we may want to reserve "src" on PyPI)
2. Use a top-level "tools" directory (we may want to reserve "tools" on PyPI)
3. Add a leading or trailing underscore to the local directory name
(as while that's legal for Python imports, it's prohibited for PyPI
project names, and hence will often sidestep naming conflicts with
published packages)

Beyond that, the only approaches I'm aware of that systematically
avoid this kind of problem at the language design level are to either
use URL-based imports (ala Java or Go), or else to have separate
syntax for "system-only" and "local resolution permitted" imports (ala
C and C++), and Guido opted not to pursue either of those strategies
for Python.

Cheers,
Nick.

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