One has a concrete proposal, the other doesn’t (yet?).
Like I said before, I’m not interested in going in that direction, because I still think the declarative approach outlined in 829 is the right way to go. But I also won’t discourage someone else from proposing an alternative and seeing where the chips land.
Fine, I’ll turn my proposal into a PEP.
But honestly, a problem here is that I don’t see a way to advocate for “do nothing, all of this simply isn’t worth the upheaval”. Which is really what I think[1]. My gut feeling from this thread is that there isn’t a huge amount of support in the community for the proposal - but I’m very aware that who posts in this type of thread is a very unbalanced cross-section of the community. On the other hand, I know of no way of getting a sense of what the SC might think of the proposal, so I’m left in a position where I feel that I need to submit a “damage limitation” PEP that explains how to get most of the benefits of PEP 829 without the disruption of a new file format - particularly if you’re using the argument that PEP 829 is the better option because it has a formal proposal…
With the proviso that I believe that deprecation of “extra code on the import line” in .pth files could have been achieved with nothing more than the normal PR process, if we hadn’t already escalated the debate into PEP territory. ↩︎
If we really need to write a counter PEP just to say no to this one then here you go…
Lets leave .pth files alone.
Breaking stuff without good motivation is unhelpful.
We will make the following changes:
No changes being proposed actually fix anything wrong with .pth files (which in itself, no-one can define) or provide any new functionality that we have any use for.
None. Not even for the use cases we didn’t even know about.
Not doing anything that could be misconstrued as a security feature is a security feature!
Python users who don’t know or care that we’re having this discussion may carry on doing so.
See any semi-recent Python version.
Descoping existing .pth files so they can at most, import another module with side effects to achieve the same thing
Why bother? It achieves the same thing.
Turning .pth files into a structured config file
Same again.
(Sorry, I couldn’t help myself 
)
It seems like this alternative should just be a “rejected idea” in the pep, with an actual explanation why it wasn’t the preferred direction. The SC shouldn’t need a competing proposal just to see that argument.
That’s really the main tension I see, and that’s why I’ve been asking about the intended use cases: We want very different capabilities for external packages vs. the user’s own customization. Not even from a security standpoint, but for package interoperability and because tools need to support this, where .pth files are a problem today (that’s why I’m engaging here, I care the user experience in the interaction of these features with tools)
My experience is that these custom formats cause all sorts of problems (we certainly have them with WHEEL, METADATA and PEP 508), so I’d prefer an existing, structured format.
I agree. If the argument is, “reject this PEP for these reasons”, that should be covered in the Rejected Ideas section. Same goes for a more restrictive .pth file format if people think that doesn’t require a PEP or don’t want to write a PEP unless the SC says they prefer that approach.
@pf_moore and I had an actual conversation (imagine that!). It was quite pleasant and I think we may have some common ground. I’ll work on an updated 829 in the next couple of days.
Yep, exactly. The trick is that the narrowed syntax would be valid on all existing versions, so affected projects would just need to migrate to that narrowed format before the deprecation period ran out. No need to ship two different formats, just stop using the deprecated constructs (replacing them with an importable callable).
In the case of legacy namespace packages, it would potentially be feasible to migrate over to native namespace packages and drop the associated .pth file entirely.