Works for me El mar., 1 de ago. de 2017 11:32, Thomas Kluyver <thomas@kluyver.me.uk> escribió:
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?
On Sun, Jul 30, 2017, at 02:12 PM, Nick Coghlan wrote:
On 30 July 2017 at 02:46, Nathaniel Smith <njs@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@gmail.com | Brisbane, Australia
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig