On Windows, we are extracting a tarball of a Python installation for CI (to avoid needing to juggle umpteen Python installs on umpteen machines). This requires `PYTHONHOME` to be set to use properly since there is no registry entry for the "installation". However, `Activate.ps1` clears `PYTHONHOME` unconditionally. Is there something else we can do to properly integrate with it or should there be an option to say "no, I need `PYTHONHOME` for the stdlib to work"?

I don't know how relevant this is to other platforms at the moment as other mechanisms are sufficient there (Xcode's Python3.framework in the SDK and Linux system packages).

If `<directory of python.exe>\Lib\os.py` exists, then you shouldn't need either a registry entry or environment variable.

This sounds the same as the approach used on GitHub Actions and Azure Pipelines, and also through the packages at https://www.nuget.org/packages/python. These work fine, as far as I'm aware.

If there is some other reason you need PYTHONHOME to be set inside an activated virtual environment, you could set it _after_ activating the environment, or just modify the Activate.ps1 that is included in your tarball.

However, I seem to recall there were some fairly obscure bugs if a venv didn't resolve itself normally. So your best bet is to make sure that it can be resolved without needing the setting.

We build our own applications which run Python interpreters internally, so the auto-discovery won't work. It also doesn't seem to work for venvs either since the venv's `python.exe` is under `Scripts` which makes it not able to find things either on its own.

I've worked around it so far by just ignoring `Activate.ps1` completely and setting up PATH, PYTHONHOME, and PYTHONPATH instead, but this tells me that `Activate.ps1` probably needs some consideration for other use cases. The layout certainly seems wrong for auto-discovery at least.

> I've worked around it so far by just ignoring `Activate.ps1` completely and setting up PATH, PYTHONHOME, and PYTHONPATH instead

This sounds like the right approach. Though if you're genuinely embedding Python in your application you should consider just including a copy of the runtime that you can fully control.

> this tells me that `Activate.ps1` probably needs some consideration for other use cases. The layout certainly seems wrong for auto-discovery at least.

Activate.ps1 only has one use case: to activate a virtual environment created with -m venv against a regular installation. Once you're customising the base install, you can use a python._pth file [1], a regular .pth file [2], or environment variables, but the venv tool isn't really for that case.

1: https://docs.python.org/3/using/windows.html#finding-modules
2: https://docs.python.org/3/library/site.html