[issue33944] Deprecate and remove pth files

Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Michel Desmoulin added the comment: Just realized it didn't work in venv anyway. -- ___ Python tracker ___ ___ Python-bugs-list

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: No. You can't put an usercustomize in a wheel. -- ___ Python tracker ___ ___

[issue33944] Deprecate and remove pth files

Michel Desmoulin added the comment: Can usercustomize.py be used as an alternative to "*.pth" execution magic ? -- nosy: +Michel Desmoulin ___ Python tracker ___

[issue33944] Deprecate and remove pth files

Stéphane Wirtel added the comment: New changeset d1d968d45df1a900b0600c4d296b180aa978336d by Stéphane Wirtel (Miss Islington (bot)) in branch '3.8': bpo-33944: note about the intended use of code in .pth files (GH-10131) (GH-15942)

[issue33944] Deprecate and remove pth files

Change by miss-islington : -- pull_requests: +15577 pull_request: https://github.com/python/cpython/pull/15942 ___ Python tracker ___

[issue33944] Deprecate and remove pth files

miss-islington added the comment: New changeset f9b5840fb4497a9e2ba2c1f01ad0dafba04c8496 by Miss Islington (bot) (native-api) in branch 'master': bpo-33944: note about the intended use of code in .pth files (GH-10131)

[issue33944] Deprecate and remove pth files

qix- added the comment: -1 This would make `better_exceptions` irreparably un-ergonomic. https://github.com/qix-/better-exceptions .PTH files are commonly used to install development middleware in order to enhance the development and debugging experience. I recognize the need for

[issue33944] Deprecate and remove pth files

Change by Chih-Hsuan Yen : -- nosy: +yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Change by Ned Batchelder : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Brett Cannon added the comment: We could also have a new namespace package which is *just* for startup injection so it wasn't such a hack to tie into the codecs startup code. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: Just noting that https://bugs.python.org/issue14803 is probably our most comprehensive discussion of the coverage use case for arbitrary pre-__main__ code execution. Steve also made a comment above about potentially turning encodings into a namespace

[issue33944] Deprecate and remove pth files

Thomas Kluyver added the comment: As a lurker on this issue: I think a lot of energy is being expended arguing about what is and isn't legitimate use cases, when there's actually more stuff that people agree about than not. I think this issue should be broken down into two, neither of which

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: > You mean extra junk like .pth files? I don't see the difference between a .py > file and a .pth file, except I can’t opt out of .pth files. And you get multiple lines of code, and syntax highlighting, and linting, and all the other goodness in a genuine

[issue33944] Deprecate and remove pth files

Eric V. Smith added the comment: >> I should have to start that package somehow. > > `pip install` is a pretty good opt-in already imo I think that’s where we disagree. Like others, I don’t want this to affect every python script in a given installation. >> Instead of just shipping

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: Nonetheless, it's still something that we could support better. If telling someone to set PYTHONSTARTUP is too hard, then we can design another way that can work well without relying on a barely documented (mis)feature. As one idea, we could add a way to

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 7, 2019, at 10:46, Ionel Cristian Mărieș wrote: > > There's a simple `if 'COVSOMETHING' in os.environ` check to activate it. > That can't cost a significant amount of time. This is rather another bad > actor argument. You’re overlooking the

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: What module? That check should be done directly in the pth file. -- ___ Python tracker ___

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: > because you’re on the same machine and you pip installed it, I have no > choice but to pay those costs, which I haven’t explicitly opted in to. > > At least for the coverage plugins there is a required opt in from > environment variable (as shown

[issue33944] Deprecate and remove pth files

Brett Cannon added the comment: RE: " So basically you'd remove the whole feature just cause one package no one installs abuses it. Doesn't make sense." No, the point being made is *at least* one package that was found on PyPI is abusing it, so it exists and we need to consider the possibility

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: >>> I should have to start that package somehow. >> >> `pip install` is a pretty good opt-in already imo > > Except that it conflates responsibilities. I may not want to opt into > coverage even being loaded in my application because I’m not going to use it

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 7, 2019, at 09:32, Anthony Sottile wrote: > >> I should have to start that package somehow. > > `pip install` is a pretty good opt-in already imo Except that it conflates responsibilities. I may not want to opt into coverage even being loaded in

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 7, 2019, at 07:38, Steve Dower wrote: > > Steve Dower added the comment: > > There are two features here, let's be clear about what we're removing. > > * extending sys.path with static (perhaps relative) directories > * arbitrary code execution

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: > What I'm dismissing is that "pip install some-package" can define a global > startup task for your interpreter. I shouldn't get debugging or code coverage > enabled every time I run "python" just because I installed some package At least for the coverage

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: > I don't think there would be an alternative to how these tools function if > this feature were removed. Right now, maybe, which is why we haven't just removed it :) The point of the discussion is to say "this functionality is irreplaceable so we need to

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: Here's a trivial workaround for the import hook problem: Assume we have "my_module.foo", and the import hook enables importing foo files. Instead of just shipping "my_module.foo", you ship "my_module.py" and "_my_module.foo", where "my_module.py" looks like:

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: > Elaborate please, as it sounds like you're simply dismissing my usecase. I'm suggesting that to enable this functionality at startup, the user/application should have to do something like executing code or setting PYTHONSTARTUP. What I'm dismissing is that

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: I think nearly all of the use cases in the packages are valid (except module-layout) -- or at least if this feature were removed without having a startup-time site-packages code execution feature there would be no possible replacement. I'll elaborate a

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: > * coverage, debugging, demo, except-hook - application/user responsibility, not a package's Elaborate please, as it sounds like you're simply dismissing my usecase. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: There are two features here, let's be clear about what we're removing. * extending sys.path with static (perhaps relative) directories * arbitrary code execution (following "import " statements) Only Barry wants to remove the first one, and the rest of us will

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: > Doesn’t that kind of prove my point? :) So basically you'd remove the whole feature just cause one package no one installs abuses it. Doesn't make sense. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: > Doesn’t that kind of prove my point? :) It's not any worse than gevent ~breaking~ monkeypatching almost the entire standard library. And to be fair to the author, it was created well before (2013-06-21) python3.5's `run` api existed (2015-04-14) It's

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 6, 2019, at 19:04, Anthony Sottile wrote: > It assigns `subprocess.run`, which is an api in python3.5+. In those > versions, `subprocess.check_*` is implemented in terms of `subprocess.run`. > The `subprocess.run` provided by that package has a

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: > > There was a single .pth file that I deemed "malicious" since it completely breaks the `subprocess` module (`subprocess-run`) > > It only seems to set an attribute. What's wrong with that? Does the early import of subprocess cause problems? It assigns

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: > There was a single .pth file that I deemed "malicious" since it completely breaks the `subprocess` module (`subprocess-run`) It only seems to set an attribute. What's wrong with that? Does the early import of subprocess cause problems? --

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: I did my best to classify those on pypi that were using `.pth` files. My initial search had quite a few false positives (and now that I look at it, completely missed `.zip`-based source distributions so there's likely some false negatives as well) Here's

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On 02.03.2019 9:01, Barry A. Warsaw In all the cases you've described, Python is no different from any other Linux software. E.g. I can install something into /etc/profile.d that would break the shell or set an envvar that would change the behavior of

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 1, 2019, at 19:59, Ivan Pozdeev wrote: > > Ivan Pozdeev added the comment: > > On 02.03.2019 2:25, Barry A. Warsaw wrote: >> The fact that .pth files are global and affect the entire Python >> installation. <...> Right now, there’s no control over

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On 02.03.2019 2:25, Barry A. Warsaw wrote: > The fact that .pth files are global and affect the entire Python > installation. <...> Right now, there’s no control over the scope of such > environmental customizations; it’s all or nothing. That's the entire

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: Barry's response in https://bugs.python.org/issue33944#msg336970 is exactly what my response to that point was going to be. Just because I want to use package spam and it wants to use package eggs doesn't mean that eggs gets to enable cloud imports (or

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Mar 1, 2019, at 09:27, Ivan Pozdeev wrote: > Startup code (custom or not) is not a dependency of anything. It rather > customizes the environment in which the program specified by the user would > run, _before_ any user code could be allowed to get

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: I don't have time to look through the data today but I wrote a script to collect the usages of `.pth` from pypi. I realized after I ran it that I skipped source distributions with `.zip` extension but otherwise it's pretty complete:

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On 01.03.2019 20:27, Ivan Pozdeev wrote: > The fact that this feature is mixed up with and often supplements > "real packages" that a program would explicitly use is actually > incidental: a package with a .pth does not need to have any > functionality

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On 01.03.2019 3:58, Steve Dower wrote > Import hooks can always be injected by a package __init__.py before the > importer will try and resolve the module, so nothing is needed there. I thought the flaw in this reasoning in

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: The sitecustomize.py file is totally available, and the only limitation there is packages can't inject themselves into it on installation. And if you want to trigger it on a package import then you totally can (though there's *another* discussion about that

[issue33944] Deprecate and remove pth files

Change by Ivan Pozdeev : -- pull_requests: +12117 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On second thought, the inability to debug code that runs at startup, before user code ever gets control, is a fundamental issue (this problem arises for any software that has startup code), so such a facility in stock codebase has a merit. --

[issue33944] Deprecate and remove pth files

Change by Ivan Pozdeev : -- pull_requests: +12114 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: > What I think Anthony is looking for are ways to register “start up functions” > that get executed automatically when the Python interpreter starts up yes, this is what I want to still exist :) my hope is that there's a clear standards-track replacement

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Feb 28, 2019, at 09:40, Anthony Sottile wrote: > > I don't think even this is unanimous. Things like registering codecs, > instrumenting coverage in subprocesses, etc. all seem like legitimate uses of > the arbitrary code execution feature Except pth

[issue33944] Deprecate and remove pth files

Anthony Sottile added the comment: > contain features we all want to get rid of I don't think even this is unanimous. Things like registering codecs, instrumenting coverage in subprocesses, etc. all seem like legitimate uses of the arbitrary code execution feature --

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: > But think of the poor user who doesn’t have that expertise or ability to hack > on an installed Python’s site.py file. This is actually part of the thinking behind the reportabug tool I started (and why when you format it as raw text you get the listing of

[issue33944] Deprecate and remove pth files

Peter L added the comment: +1 for python -v listing .pth files found and loaded. For debugging, I just add a: import sys; print('Loading mypth.pth') to the start of the pth file. A plain print doesn't work(?). breakpoint() doesn't work(?). It would be nice to be able to get the filename

[issue33944] Deprecate and remove pth files

Change by Peter L : -- nosy: +Peter L3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: On Wed, Feb 27, 2019 at 1:41 AM Barry A. Warsaw wrote: > Basically yes, I’ve done this. But think of the poor user who doesn’t have that expertise or ability to hack on an installed Python’s site.py file. When their application breaks because some

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: On Wed, Feb 27, 2019 at 1:31 AM Barry A. Warsaw wrote: > Your sudo may not be my sudo. :) Let’s say I update my Ubuntu desktop and a new version of package with a pth breaks. > Maybe I didn’t even know I was doing that, via automated updates, or

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Feb 26, 2019, at 13:23, Ivan Pozdeev wrote: > > Easy. Insert a chunk into site.py that would call pdb.set_trace() if an > envvar (e.g. `PYSITEDEBUG') or a command line switch is set. > > Actually, why can't whoever has this problem add such a chunk

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:52, Ionel Cristian Mărieș wrote: > > Something bad was installed with sudo but suddenly sudo is not acceptable for > debugging? This seems crazy. Your sudo may not be my sudo. :) Let’s say I update my Ubuntu desktop and a new

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: Barry is a steering council member now, so by definition he's 1/5th of the loudest possible minority ;) I am totally okay with adding more diagnostics here. Frankly, if "-v" doesn't currently log info about .pth files (or other things that the site module does

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: On 26.02.2019 23:37, Barry A. Warsaw wrote: > My opposition would lessen if there were clear ways to debug, and preferably > also prevent, pth interpretation. Easy. Insert a chunk into site.py that would call pdb.set_trace() if an envvar (e.g. `PYSITEDEBUG')

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: > Because there’s no good place to stick a pdb/breakpoint to debug such issues > other than site.py, and that usually requires sudo. Something bad was installed with sudo but suddenly sudo is not acceptable for debugging? This seems crazy. How

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:32, Steve Dower wrote: > > There are 100 other ways to end up in this situation though. Why is *this* > one so much worse? Because there’s no good place to stick a pdb/breakpoint to debug such issues other than site.py, and that

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: > Extending sys.path is a useful use case, but doing so in pth files is > problematic. There are 100 other ways to end up in this situation though. Why is *this* one so much worse? Can you offer an issue you hit that was caused by a .pth file that *wasn't*

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Feb 26, 2019, at 05:19, Nick Coghlan wrote: > > I just don't want to lose the "add this location to sys.path" behaviour that > exists for lines in pth files that *don't* start with "import ", since that > has plenty of legitimate use cases, and the only

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: Yep, I completely understand (and agree with) the desire to eliminate the code injection exploit that was introduced decades ago by using exec() to run lines starting with "import " (i.e. "import sys; "). I just don't want to lose the "add this location to

[issue33944] Deprecate and remove pth files

Steve Dower added the comment: I took a look at the docs PR, and honestly I don't even get what the "intended" uses of executable code are supposed to be. The examples are "load 3rd-party import hooks, adjust PATH variable", but the only cases I can think of where you'd need to do these in

[issue33944] Deprecate and remove pth files

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Change by Steve Dower : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

STINNER Victor added the comment: > 3. I realize that PEPs are needed for any change and even to define what > that change might look like, but is there any value in adding > PendingDeprecationWarnings for 3.8 if that's a possible action that will > happen? As I understand it, it would be

[issue33944] Deprecate and remove pth files

Cheryl Sabella added the comment: Hello all, There was a lot of traction on this discussion a month ago and I was wondering if any updates/expectations should be set? Specifically: 1. There is a PR for a doc change that Terry approved, but wanted another core dev to look at. If there is

[issue33944] Deprecate and remove pth files

Ionel Cristian Mărieș added the comment: FYI I have 3 projects that use pth files to activate various features (an env var is usually the trigger): https://pypi.org/project/pytest-cov - enables coverage measurement in any subprocess https://pypi.org/project/manhole - installs a debug service

[issue33944] Deprecate and remove pth files

Vedran Čačić added the comment: I have a directory inside my home directory, and inside it I have files with various utilities I have written over the years. So far, whenever I have installed a new version of Python, I have simply put a util.pth into site-packages. If you remove that

[issue33944] Deprecate and remove pth files

Chris Billington added the comment: > Linux distros approach to handling this is terrible because they dump all > their system packages into a single global site-packages, leading to the > every growing sys.path problem that Barry is concerned about. > However, that's entirely the fault of

[issue33944] Deprecate and remove pth files

STINNER Victor added the comment: > SyntaxError: encoding problem: future_fstrings IMHO that's the expected behavior. I would prefer to have to explicitly install this special encoding *before* loading a script using it. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Jason R. Coombs added the comment: > `site.addsitedir` is called for every site-packages directory (whether > global, within a venv, or at the user level), so my proposal above covers > appending multiple segments. Good point. I think you're assuming that only site dirs are appropriate for

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: Note that any PEP I contributed to writing would need to be restricted to eliminating arbitrary code execution, as I don't think there's anything wrong with the path extension feature. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: `site.addsitedir` is called for every site-packages directory (whether global, within a venv, or at the user level), so my proposal above covers appending multiple segments. Linux distros approach to handling this is terrible because they dump all their

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Jan 14, 2019, at 17:30, STINNER Victor wrote: > > I don't think that you will like it, but I feel that a PEP will be needed > here to list use cases and explain what replace .pth files for each use > case. Maybe no replacement for some use cases is fine.

[issue33944] Deprecate and remove pth files

STINNER Victor added the comment: I don't think that you will like it, but I feel that a PEP will be needed here to list use cases and explain what replace .pth files for each use case. Maybe no replacement for some use cases is fine. The PEP doesn't have to be long. I also expect that it's

[issue33944] Deprecate and remove pth files

Antoine Pitrou added the comment: > Is that true outside of virtual environments? Not in my experience. But I'm not sure special-casing virtual environments will make the situation easier to understand ;-) -- ___ Python tracker

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Jan 14, 2019, at 07:17, Nick Coghlan wrote: > > I'll also reiterate that I am *completely* opposed to deprecating the "append > entries to sys.path" usage model, as there is absolutely nothing wrong with > that (if distros are ending up with an overly

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Jan 14, 2019, at 04:14, Antoine Pitrou wrote: > > As I said: editable installs (`pip install -e`) are an important use case of > .pth files. Is that true outside of virtual environments? I care less about .pth files inside venvs, since those are

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Jan 14, 2019, at 04:02, STINNER Victor wrote: > > I really hate .pth files because the slow down Python startup time for *all* > applications whereas .pth files are usually specific to a very few > applications using one or two specific modules. > >

[issue33944] Deprecate and remove pth files

Jason R. Coombs added the comment: I like Nick's proposal. It has I believe the features that satisfy the use-cases of which I'm currently aware... with one edge case you may not have considered - support for multiple `__sitecustomize__` locations. Consider, for example, the case where

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: Namespace packages in general didn't rely on pth files - only the setuptools/pkg_resources implementation of them did. I'll also reiterate that I am *completely* opposed to deprecating the "append entries to sys.path" usage model, as there is absolutely

[issue33944] Deprecate and remove pth files

Change by SilentGhost : -- nosy: +SilentGhost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Antoine Pitrou added the comment: As I said: editable installs (`pip install -e`) are an important use case of .pth files. I don't see how namespace packages have anything to do with this, sorry. -- ___ Python tracker

[issue33944] Deprecate and remove pth files

STINNER Victor added the comment: I really hate .pth files because the slow down Python startup time for *all* applications whereas .pth files are usually specific to a very few applications using one or two specific modules. They can also modify the behavior of Python for all applications,

[issue33944] Deprecate and remove pth files

Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: > This brings to mind the transition of many programs from using a single > config file or startup script to using a directory of config/startup files > parsed/executed in alphabetical order. Would a sitecustomize.d/ directory > (with files within it executed

[issue33944] Deprecate and remove pth files

Chris Billington added the comment: coverage.py's documentation mentions: > The sitecustomize.py technique is cleaner, but may involve modifying an > existing sitecustomize.py, since there can be only one. If there is no > sitecustomize.py already, you can create it in any directory on the

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: I'm suggesting PendingDeprecationWarning because we can't *actually* deprecate anything until we provide a more transparent alternative that offers comparable functionality, and I haven't seen a credible proposal for a replacement yet. So using PDW would

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: > To make a potentially viable concrete proposal here, I think a reasonable > first step would be to change the ".pth" file processing code in site.py to > emit PendingDeprecationWarning for the 'if line.startswith(("import ", > "import\t")):' branch.

[issue33944] Deprecate and remove pth files

Nick Coghlan added the comment: To make a potentially viable concrete proposal here, I think a reasonable first step would be to change the ".pth" file processing code in site.py to emit PendingDeprecationWarning for the 'if line.startswith(("import ", "import\t")):' branch. In addition to

[issue33944] Deprecate and remove pth files

Chris Billington added the comment: I develop analysis software for physics research, in which the user analyses their data using Python that they write themselves (my application functions as a kind of scheduler for when the analysis scripts should run and with what input). This software

[issue33944] Deprecate and remove pth files

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33944] Deprecate and remove pth files

Jason R. Coombs added the comment: Regarding other uses of .pth files, the project [future-fstrings](https://github.com/asottile/future-fstrings) relies on .pth files to enable its at-startup behavior. I'm also +1 to remove .pth files, but I also believe it's not viable today due to

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: > I’m a little concerned about this approach because it means random third > party modules can affect the global environment for your application, without > knowing it. Since the hook installation happens at import time, and just > depending on a library that

[issue33944] Deprecate and remove pth files

Barry A. Warsaw added the comment: On Nov 10, 2018, at 04:50, Ivan Pozdeev wrote: > In its .pth file, each such package will import the hook's module (which will > cause the hook to be installed on the first import) and "register" its > namespaces and/or dependencies with it. The hook will

[issue33944] Deprecate and remove pth files

Ivan Pozdeev added the comment: @barry > Interdependent namespace packages. If they get loaded in the wrong order, > they can mess up __path__ settings Actually, when writing the PR, I had a revelation how this could be implemented. Via an import hook that would work like a union FS! In

  1   2   >