<p dir="ltr">Works for me</p>
<br><div class="gmail_quote"><div dir="ltr">El mar., 1 de ago. de 2017 11:32, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are we content to say that sys.path includes the source directory where<br>
the hook is run? Shall I prepare a PR against the PEP for that?<br>
<br>
On Sun, Jul 30, 2017, at 02:12 PM, Nick Coghlan wrote:<br>
> On 30 July 2017 at 02:46, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
> > Or am I worrying about a non-issue and it's fine if flit imports click from<br>
> > the source tree?<br>
><br>
> Don't worry about it too much, as the problem here isn't really any<br>
> worse than it is for normal runtime dependencies of any other project<br>
> that relies on having the current directory first in sys.path. It just<br>
> so happens that the project in question in this case is a Python<br>
> project's build system.<br>
><br>
> Due to the preference for a flat module namespace as the default,<br>
> there are plenty of ways to hit name shadowing problems in Python, and<br>
> as Donald notes, build systems have other motives to vendor their<br>
> dependencies rather than installing them normally.<br>
><br>
> Just switching the path order as has been suggested also doesn't solve<br>
> the problem, as it merely inverts the issue: having "some_name"<br>
> installed in site-packages would break source installations of<br>
> packages that expected to be able to import "some_name" from their own<br>
> root directory.<br>
><br>
> If the problem does come up in practice, then there are a number of<br>
> ways for affected projects to work around it in their project<br>
> directory structure:<br>
><br>
> 1. Use a top-level "src" directory (we may want to reserve "src" on PyPI)<br>
> 2. Use a top-level "tools" directory (we may want to reserve "tools" on<br>
> PyPI)<br>
> 3. Add a leading or trailing underscore to the local directory name<br>
> (as while that's legal for Python imports, it's prohibited for PyPI<br>
> project names, and hence will often sidestep naming conflicts with<br>
> published packages)<br>
><br>
> Beyond that, the only approaches I'm aware of that systematically<br>
> avoid this kind of problem at the language design level are to either<br>
> use URL-based imports (ala Java or Go), or else to have separate<br>
> syntax for "system-only" and "local resolution permitted" imports (ala<br>
> C and C++), and Guido opted not to pursue either of those strategies<br>
> for Python.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>