# Idea: requiring per-package opt-in for installation of implicit startup files **URL:** \ **Category:** Packaging\ **Created:** [March 25, 2026, 11:00am UTC](https://discuss.python.org/t/idea-requiring-per-package-opt-in-for-installation-of-implicit-startup-files/106678 "2026-03-25T11:00:46Z")\ **Posts on this page:** 3\ **Page:** 4
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [April 9, 2026, 3:43pm UTC](https://discuss.python.org/t/idea-requiring-per-package-opt-in-for-installation-of-implicit-startup-files/106678/61 "2026-04-09T15:43:00Z")
> [@abravalheri](#): > > one of the main criticisms (if not THE MAIN) with the setuptools implementation of editable installs is that static analysis tools cannot cope with the dynamic effects of it. More precisely, the use of `.pth` files to add directories to `sys.path` is well known and supported by most static analysis tools. Anything that requires code execution to dynamically affect the import system (import hooks, self-replacing modules, etc) is not amenable to static analysis and therefore makes editable installs distinctly more difficult to work with than “normal” installs. A standard for statically describing _all_ of the possible semantics of editable installs (which could either incorporate or supersede `.pth` files, depending on backward compatibility considerations) would be a significant advantage for such tools. We could then have a mechanism for implementing an editable install based on that static description. That mechanism could be a 3rd party library\[1\] or it could be in the core interpreter or stdlib\[2\]. Unfortunately, no-one has yet shown any interest in doing this work - neither formally defining what it means to be an “editable install”, nor standardising a static description mechanism. And to be explicit here, it’s _not_ something I want to implement in the `editables` library - it’s more than I personally have time to develop or support, so I’d rather leave it to someone who does have the necessary time\[3\]. Full disclosure: This is very close in some ways to the idea proposed in [PEP 662](https://www.python.org/dev/peps/pep-0662/). And as such it has the same problems as that PEP - it’s easy to talk in generalities, but to be useful, there’s a whole lot of detail that needs to be thrashed out by _someone_. * * * 1. Which would need to be activated early in the interpreter startup process, something that currently requires the “execute arbitrary code at startup” feature of `.pth` files 2. Taking advantage of the core’s privileged position of having direct access to the interpreter startup machinery 3. I’d be interested in contributing to such an effort, but wouldn’t want to lead it ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [April 10, 2026, 2:53am UTC](https://discuss.python.org/t/idea-requiring-per-package-opt-in-for-installation-of-implicit-startup-files/106678/62 "2026-04-10T02:53:16Z")
> [@abravalheri](#): > > Given this scenario, it would be good that any proposal intended to replace or deprecate current `.pth` files offer an equivalent expressive power. I believe what we discussed as the next draft of 829 will work with these two cases. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [April 10, 2026, 9:45am UTC](https://discuss.python.org/t/idea-requiring-per-package-opt-in-for-installation-of-implicit-startup-files/106678/63 "2026-04-10T09:45:59Z")
> [@abravalheri](#): > > The approval and subsequent implementation of PEP 660 was a notably bumpy process, largely because editable installs are a genuinely hard problem. A key difficulty is that the term “editable install” itself is overloaded, and users employ it conflicting expectations Which is why my position the whole way through was to avoid over-specifying how they should work. There’s absolutely no harm in letting tools provide any option they want here, provided the term “editable install” is defined only well enough to exclude things that are obviously not editable installs (such as system-provided packages or install-on-demand packages or a range of _obvious_ things that we _don’t_ mean). The process was bumpy because people insisted on trying to codify a specific behaviour. From the POV of running code at startup, I think the way setuptools does it is basically fine (the distutils hack could’ve been pushed into the module rather than checking environment variables in the `.pth` file, but no big deal), and already consistent enough with the more restricted model that Barry is proposing.\[1\] I’m also personally just fine with the current `.pth` behaviour and don’t see a need to restrict or change it at the core level. I’d be quite okay with limiting or restricting whether packages from online can create/install `.pth` files, but once they’re on disk, I think they’re already fine. Which means my position is that editable installs should get 100% expressive power, because they are entirely local.\[2\] The “laziness” was only really referring to “hey, we can write code in the `.pth` file instead of putting it in a `.py` file and installing that as part of setting up the editable install”. Maybe it wasn’t considered, maybe it was, I don’t know. I’m sure every time it came up during the original discussions it was swamped by other threads, and I did follow that discussion closely enough to count myself part of it (though I didn’t contribute much). So I don’t think I meant it in an unfair way, though of course it’s possible to take it in a way that feels unfair. I apologise if that led to any offence being taken. No voluntary contribution can ever be the result of laziness, but perhaps I have that so internalised that I didn’t consider others might read it as “he was so lazy that he made something and gave it away for free” 😃 * * * 1. Though I haven’t seen the update post that he mentioned yet. 2. And online installs should probably get 0% power, since the only choices are 0% or 100% and we don’t really like giving them 100%. [Previous page](https://discuss.python.org/t/idea-requiring-per-package-opt-in-for-installation-of-implicit-startup-files/106678.md?page=3)