Idea: requiring per-package opt-in for installation of implicit startup files

[barry (Barry Warsaw)]

@brettcannon

So convert a .pth file into a TOML file which separates out the path extending with the code execution?

Effectively yes. In my mind we also separate the processing of these TOML files into two phases: a discovery/parsing phase and an execution phase. That would let us do some interesting things^[1] such as apply a policy to path extension and code execution.

@brettcannon

As long as we make it cheap to discover the file like it is for .pth files I think that’s a reasonable idea.

It should be as easy as .pth discovery, since in my mind, this TOML file would sit exactly where the .pth file would sit.

@brettcannon

I’m assuming TOML so it’s easier to audit by a person (versus JSON which is probably easier to parse overall but potentially harder to read)?

Yep. It would probably be generated by packaging tools, but I do think human readability^[2] is important. Now that we have TOML parsing in the stdlib, I think this is a totally reasonable approach. We can even lazy import tomllib

@brettcannon

I think one benefit to the entry point approach is it probably makes malware scanning easier as I bet most scanners don’t check .pth files.

Yep!

@brettcannon

Are we serious enough about this idea to keep talking about it? And do we want a separate topic or just do it here?

I am! I’m actually working on a pre-PEP and a prototype to explore the schema and semantics, but I think it all falls out pretty naturally^[3]. I can create a separate topic once I have something a bit more concrete to share, but reach out if you want to collaborate.

---

1. likely deferred to the future ↩︎

2. and maybe writeability ↩︎

3. ! ↩︎