PyPA-Committers February 2022

pypa-committers@python.org

22 participants
3 discussions

Vote: Accept installer within the PyPA
by Pradyun Gedam 11 Mar '22

11 Mar '22

The proposal: Adopt https://pypi.org/p/installer into the PyPA. Functionally, this means transferring https://github.com/pradyunsg/installer to the `pypa` organisation on GitHub. The proposal was first put forward at https://discuss.python.org/t/13778. If there's any discussions or comments, please direct them there. Relevant section from PEP 609: > The proposal will be put to a vote on the PyPA-Committers mailing list, over a 7-day period. Each PyPA committer can vote once, and can choose one of +1 and -1. If at least two thirds of recorded votes are +1, then the vote succeeds.

22 22

Re: Vote: Accept installer within the PyPA
by Henry F. Schreiner 18 Feb '22

18 Feb '22

1 0

Please be mindful of concurrency limits for GitHub Actions
by Dustin Ingram 11 Feb '22

11 Feb '22

Hi folks, Reminder that projects in the https://github.com/pypa org share a limit of 20 concurrent jobs <https://docs.github.com/en/actions/learn-github-actions/usage-limits-billin…>. Workflows in your project with long-running jobs or a large number of jobs will slow down the build queue for other projects in the org. A few changes you can make to your workflows to consume less resources without changing your jobs themselves: *Only run CI workflows on PRs and pushes to the default branch* Without this, workflows will be triggered for pushes to branches that do not have corresponding PRs, and pushes to branches that *do* have corresponding PRs will run each workflow twice. An example to add to your workflow: on: push: branches: - main pull_request: *Consider running expensive workflows on tags only* Some expensive workflows might not need to run on PRs or every push to your default branch, and can be restricted to run on tags only. An example to add to your workflow: on: push: tags: - '*' *Use concurrency groups <https://docs.github.com/en/actions/using-jobs/using-concurrency> and cancel-in-progress:* Concurrency groups are a way to mark related jobs as being in the same group. By grouping jobs based on pull request # or SHA, and combining this with the cancel-in-progress setting, new commits added to the same concurrency group will cancel in-progress jobs on previous commits. An example to add to your workflow (taken from pypa/pip/.github/workflows/ci.yml <https://github.com/pypa/pip/blob/ec8edbf5df977bb88e1c777dd44e26664d81e216/.…> ): concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }} cancel-in-progress: true (Note that GitHub's example of ${{ github.workflow }}-${{ github.ref }} will have the effect of cancelling in-progress jobs on the default branch, which is generally not desirable) Thanks!

1 0

2022

2021

2020

2019

2018

PyPA-Committers February 2022