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