[Distutils] PEP 517: Build system API

Wes Turner 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
> <javascript:;>> wrote:
> > On 25 November 2016 at 14:04, Nick Coghlan <ncoghlan at gmail.com
> <javascript:;>> wrote:
> >> 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
> replacement.
>
> 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
> versions.
>
> > 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
> start-up


There's

 python -m site

But is there a -m tool for checking .pth files?
(For code in .pth.py files)?

...

def cache_pth_sys_path(file='cached_pth.pyc'):
    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) # ...


def iter_pth_files():
    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
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com <javascript:;>   |   Brisbane,
> Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161126/25fc8479/attachment.html>


More information about the Distutils-SIG mailing list