Mailman 3 February 2022 - PyPA-Committers

Vote: Accept installer within the PyPA
by Pradyun Gedam March 11, 2022

March 11, 2022

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 Feb. 18, 2022

Feb. 18, 2022

+1

1 0

Please be mindful of concurrency limits for GitHub Actions
by Dustin Ingram Feb. 11, 2022

Feb. 11, 2022

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