Some other code could be misusing “__PYVENV_LAUNCHER__”, so I’d still prefer for the new launcher to always delete this variable. I don’t know if anyone is using this ‘private’ environment variable, but it wouldn’t surprise me. IIRC, the use of a launcher for virtual environments did lead to a couple of reported issues for applications that assume there’s no intermediating launcher between the current process and the Python process. The workaround is to spawn the base Python and use “__PYVENV_LAUNCHER__”, like multiprocessing does, but a naive implementation might just set this variable in its own environment to be inherited by all of its child processes.
GitHub - brettcannon/python-launcher: Python launcher for Unix specifically, and as Steve said it’s for Unix, in Rust, and is entirely oriented towards the “shortcut to launch
python” use-case and none of the “make a file a more self-contained Python app” use-cases that Paul is asking about.
The Python Launcher for Unix may get refactored into a Rust library crate and then have Python bindings for its location abilities. Basically I want the code we have in VS Code for discovering Python environments to be available outside of the extension, and I think having the code in Rust/Python is more useful than TypeScript (which would also mean PEP 514 support eventually).
I am also tossing around an idea of some sort of locator API to let tools participate in the location of environments via specially-named binaries. That way anyone who has their own tool that manages environments or puts their Python binaries in interesting places can still be found.
While there might be times when it’s desirable for the child to outlive the launcher, I’m not sure how common that case is. The most recent
distlib issue relates to the child outliving the launcher.
This in the context of the launcher getting a console close, logoff, or shutdown event. At most a process can delay returning from the handler while performing a clean exit. However, if the handler doesn’t return before the system’s hung-app or shutdown timeout value, Windows simply terminates the process. Thus decoupling the launcher and Python process is harmless in this case. It’s the only way to guarantee that a console control handler in the Python process will have the chance to exit cleanly.
I’m guessing you’re talking about python/devguide#848, for reference?
There’s still the Experts Index in the devguide—are you referring to something BPO-specific?
It is now, though there hasn’t yet been a
distlib release with that change.
Well, I’m not sure the experts index is especially relevant in this case (as a means for deciding who should be contacted about an issue or PR) - the launcher would perhaps be in the “Miscellaneous” category at the bottom of that devguide document. It would be easier to find interested parties from
git blame or the header comment of
PC/launcher.c. And as for
I added myself to the
CODEOWNERS file for stuff I maintain three years ago. This should in theory get GitHub to add me as a potential reviewer for any PR relating to this code, but AFAICT there was no PR for this change, it seems to have been directly committed to
main. (Please correct me if I’ve misread something - but it could explain why I didn’t get invited to review anything. And while the issue was “out there”, I wasn’t nosied, so I didn’t know about it.)
I’m not sure if it would be healthy if this approach (of committing directly, without PR / review) was adopted more widely (meaning, to any part of the codebase). Surely a large/non-trivial change shouldn’t be committed directly to
main except through a PR and a review process, even by a core developer? Of course one can bikeshed about what constitutes “large”; I put all my changes through PRs even if sometimes I can’t get reviews for them from other committers. I realise that as core developers we can bypass the PR route and commit directly, but it seems good practice to use PRs and thereby ensure use of a mechanism for multiple pairs of eyes potentially examining changes.
No, the commit you are linking to is the result of doing a squash merge using the github UI. The PR for the change is linked from the commit page (
GH-nnnnnn in the title or
#nnnnnn in small text below the title): bpo-46566: Add new py.exe launcher implementation by zooba · Pull Request #32062 · python/cpython · GitHub
AFAIK core devs can’t commit to main directly, PRs are required (but reviews are not, and not all CI checks are required). Release branches also have special restrictions at release time.
Yes, the experts index was used for suggestions in the nosy box: you could type
distutils and add four usernames at once. Github labels or teams do not fully replace that feature that was used all the time.