GeezerVison is showing github.com — Implement PEP 829 - Package Startup Configuration · Issue #148641 · python/cpython
Implement PEP 829 - Package Startup Configuration #148641DescriptionFeature or enhancement
Proposal:
Reference implementation for PEP 829.
Has this already been discussed elsewhere?
DPO thread
Links to previous discussion of this feature:
No response
Linked PRs
Activitypicnixz commented on Apr 16, 2026 Disclaimer: ignore this message if your PEP was accepted by the SC
Barry, maybe you are not aware of it but we try to avoid opening issues or PRs in the main repo for PEPs reference implementations if they are not already accepted. It is preferrable to have everything in a separate repo/fork so that we only discuss the reference implementation separately, unless you need the build bot fleet to test your changes (in which case, please indicate that in the PR and issue description).
The rationale is that it is described in PEP-1:
Once the PEP is assigned a number and committed to the PEP repository, substantive issues should generally be discussed on the canonical public thread, as opposed to private channels, GitHub pull request reviews or unrelated venues.
Once a PEP has been accepted [by the SC], the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to “Final”.
So, usually (and to really enforce splitting design discussions from integration into main), we do not open issues or PRs for PEPs that are yet to be accepted. warsaw commented on Apr 17, 2026 Thanks @picnixz. I can respect that. I was wondering if the test-with-buildbots label (which isn't set on this PR) would disable buildbot fleet testing? The branch is in my fork. picnixz commented on Apr 17, 2026 Test-with-buildbots launch de buildbot fleet if your PR is opened against main and in this repo. If you create your own fork and create a PR against your own forked main, that label would not work (AFAIK) ncoghlan commented on May 2, 2026 @warsaw What do you think of the idea of enhancing python -m site to print out the list of startup files that were found and executed? Extracting a definitive version of that list at the moment is fairly painful (the most robust option I currently have is grepping the output of python -vv for references to \.pth).
The key change from the current PR would be that instead of dumping the sets of pending files entirely after processing them, we'd instead move them over to an "executed files" set, and make that available for reporting purposes (both in the module API and in the python -m site output). warsaw commented on May 2, 2026
@warsaw What do you think of the idea of enhancing python -m site to print out the list of startup files that were found and executed? Extracting a definitive version of that list at the moment is fairly painful (the most robust option I currently have is grepping the output of python -vv for references to \.pth).
The key change from the current PR would be that instead of dumping the sets of pending files entirely after processing them, we'd instead move them over to an "executed files" set, and make that available for reporting purposes (both in the module API and in the python -m site output).
I think this is a great idea. python -m site already prints out some information so this would be a simple addition. warsaw commented on May 3, 2026
@warsaw What do you think of the idea of enhancing python -m site to print out the list of startup files that were found and executed? Extracting a definitive version of that list at the moment is fairly painful (the most robust option I currently have is grepping the output of python -vv for references to \.pth).
The key change from the current PR would be that instead of dumping the sets of pending files entirely after processing them, we'd instead move them over to an "executed files" set, and make that available for reporting purposes (both in the module API and in the python -m site output).
I'll probably do this as a followup PR after the main PEP 829 one lands. Reacted by Alyssa Coghlan hugovk commented on May 3, 2026 warsaw commented on May 8, 2026 Closing this issue out as 829 should be fully implemented now.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|