<br><br>On Friday, November 25, 2016, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25 November 2016 at 12:26, Robert Collins <<a href="javascript:;" onclick="_e(event, 'cvml', 'robertc@robertcollins.net')">robertc@robertcollins.net</a>> wrote:<br>
> On 25 November 2016 at 14:04, Nick Coghlan <<a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a>> wrote:<br>
>> The bad reputation of ".pth" doesn't generally stem from their normal<br>
>> usage (i.e. just listing absolute or relative directory names that the<br>
>> import system will then append to __path__).<br>
>><br>
>> Rather, it stems from this little aspect: "Lines starting with import<br>
>> (followed by space or tab) are executed." (from<br>
>> <a href="https://docs.python.org/3/library/site.html" target="_blank">https://docs.python.org/3/<wbr>library/site.html</a> )<br>
><br>
> I think its also worth exploring a targeted, modern namespace aware replacement.<br>
<br>
Right. For a long time I thought "existing .pth files, only with the<br>
import line execution deprecated" was the only approach that stood any<br>
chance whatsoever of being adopted in a reasonable time frame, but we<br>
can technically use the "executable .pth file" trick ourselves to let<br>
people opt in to a new sys.path extension format on earlier Python<br>
versions.<br>
<br>
> That is - there are two, related, use cases for .pth files vis-a-vis<br>
> package installation. One is legacy namespace packages, which AFAICT<br>
> are still in use - the migration is "complicated". The second is<br>
> arguable a variant of that same thing: putting the current working dir<br>
> into the PYTHONPATH without putting it in PYTHONPATH.<br>
<br>
Third case: making zip archive contents available to applications<br>
without unpacking the archive first.<br>
<br>
> The former case may be sufficiently covered by (forget the pep #) that<br>
> we don't need to do anything,<br>
<br>
PEP 420, and I believe the only thing that can get tricky there now is<br>
figuring out how to do things in such a way that they work with both<br>
old-style namespace packages and the automatic Python 3 ones.<br>
<br>
> and the latter is certainly something<br>
> that we should be able to deliver without needing the turing complete<br>
> capability that you're suggesting. Something data driven rather than<br>
> code driven.<br>
<br>
While I agree with this, I think there's two pieces to it:<br>
<br>
- how to handle the data-driven use cases that we're entirely fine with<br>
- how to handle the arbitrary-code-execution use cases that we'd like<br>
to discourage, but don't want to make entirely impossible<br>
<br>
The problem with proposing an entirely new implicit path manipulation<br>
format is that if we deprecate ".pth" files entirely, then that hits<br>
*both* of those groups equally, while if we don't deprecate them at<br>
all, then neither group has an incentive to migrate to the new system.<br>
<br>
By contrast, if we only propose deprecating "import" lines in ".pth"<br>
files, and also propose a more explicit approach to automatic code<br>
execution at interpreter startup, then it's only folks relying on the<br>
arbitrary-code-execution feature that would incur any migration costs.<br>
The language level pay-offs to justify that cost would be:<br>
<br>
- simplification of the current systems for implicit code execution at start-up</blockquote><div><br></div><div>There's</div><div> </div><div> python -m site<br></div><div><br></div><div>But is there a -m tool for checking .pth files?</div><div>(For code in .pth.py files)?</div><div><br></div><div>...</div><div><br></div><div>def cache_pth_sys_path(file='cached_pth.pyc'):</div><div> for (dirpath, pth, ouptut) in iter_pth_files():</div><div> with file(pth, 'r') as f:<br></div><div> print('\n# pth %r' % (dirpath, pth), file=f)</div><div> print(output, file=f) # ...</div><div> </div><div><br></div><div>def iter_pth_files():</div><div> for dirpath in sys.path:</div><div> for pth in sorted(glob.glob(*.pth, dirpath)):</div><div> output = file(pth, 'r', utf8).read().close()</div><div> # imports = ast_imports(output) # PERF</div><div> yield (dirpath, pth, output))</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- making ".pth" files less dangerous as a format<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist - <a href="javascript:;" onclick="_e(event, 'cvml', 'Distutils-SIG@python.org')">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
</blockquote>