Works for me El mar., 1 de ago. de 2017 11:32, Thomas Kluyver <tho...@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 <n...@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 | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig