When I read this, it's not clear to me what exactly is being proposed here, it makes it seem like this is better suited for a doc.

This sentence is grammatically incorrect, and this is the only usage of the acronym which is also not explained. I suggest it is just replace with the full spelling, and corrected: "Because the current working directory isn't ..."

Done.

Where? Please provide a cross-reference to the Python documentation or packaging standards

It's not documented anywhere, it just doesn't work if you try to do it. I guess we could link to the bug report that precipitated the PEP: python/cpython#135773

Maybe a link to the source on gh?

Yeah, there's no docs I'm aware of, either. I've linked to the issue, which has discussion and explanation of the code paths. It's hard to link to "the code" (getpath.py) because it requires a lot of work to unwind the particular code paths. The issue explains it all, though.

This sentence doesn't add much. It's also somewhat confused by the next para which says that the reason they are wanted is because they're prohibited.

I would first (briefly) explain to the reader what the home field in pyvenv.cfg is for, then go on to discuss the benefits of relative paths. Assume the reader is technically competent, but doesn't have all the context you do of the history here.

@AA-Turner has a point that the subsection could benefit from restructuring in general, though:

• move the rationale paragraphs up here to the motivation section
• move some of the technical details motivation text down to the rationale section
• add the rationale for excluding the tool dependent environment portability features (those problems can be solved at the tool level, and need to be solved at the tool level because the right answers are dependent on the exact intended usage model of the relative virtual environments)

For PEP readers that aren't already familiar with the problem, the core points we want to get across are that there are use cases that rely on relative virtual environments (motivation), and while we can deal with most of the challenges involved in setting them up in ways we're happy with, the ways we have to deal with this problem are particularly horrible, and we'd like to ditch them in favour of properly defined interpreter level handling of relative paths in the home key (rationale).

Yeah, there's no docs I'm aware of, either. I've linked to the issue, which has discussion and explanation of the code paths. It's hard to link to "the code" (getpath.py) because it requires a lot of work to unwind the particular code paths. The issue explains it all, though.

The goal is to enable the basic building block of portable venvs: the runtime initializing itself properly (finding python home).

There's two main reasons it doesn't propose a detailed solution to portable venvs:

• Multiple possible implementations. Should the relative path point outside the venv? To a sub-directory? A sibling dir of the venv? Which to use depends on how the venv is copied to other locations.
• Hard questions with package installation. The discussion thread touches on this. A good example are #!python shebangs that installers rewrite. These questions are hard and require installers to figure out answers, but more importantly, they're separate from the core runtime initialization logic.

"non development environment" means where something goes after you've done your local development. Typically CI or some production environment.

The difference between the two is each have their own virtual environment created and populated from scratch. This means each has to locate Python on its own, then download and install packages. Each of these steps introduces the potential for system-specific differences. e.g. /usr/bin/python3 may differ by OS or OS version, the python on path may be affected by the shell environment, the python install may have different things installed into it, package installation is non-trivial, and etc.

Does that help explain?

Done.

Done