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