Mailman 3 - PyPA-Committers

Python Packaging Vision and Strategy
by shamika.mohanan＠pyfound.org 10 May '22

10 May '22

Hello, My name is Shamika and I am the Packaging Project Manager at the PSF. This is my first post here. As part of this role, I am planning to initiate an exercise to define the Python Packaging Vision and Strategy. I have created this document to identify objectives, stakeholders and expected timeline for this initiative- https://docs.google.com/document/d/1T4IYZT7iFTlJm3N8wh8RC58noOFG2JbBI-8DYxY… As PyPA maintainers are one of the key stakeholders, I wanted to reach out and see what the maintainers would like to get out of this exercise. I also wanted to ensure I have identified all possible objectives. Please can you review the document and let me know if you have suggestions around the objectives, possible themes and anything else that you would find useful or would improve the results. Please forward this email to anyone who should be included in this discussion. Shamika

6 8

Re: Vote on adopting the hatch project under pypa
by Henry Schreiner 29 Apr '22

29 Apr '22

+1. Shows great promise. I’ve provided support for it in scikit-hep/cookie for a while, the plugins sound exciting, and it might be the first “all-in-one” to support multiple environments and proper binary builds (via plugins). Haven’t played with it enough yet, but already like hatchling. Plus pipx already uses it. :) Henry Sent from my iPhone

2 1

Vote on comissioning new PyPA logo
by Bernat Gabor 11 Apr '22

11 Apr '22

I'm calling for a vote to create a logo for Python Packaging Authority (and sub-projects). Detailed discussion and information might be found at https://discuss.python.org/t/selecting-a-logo-for-the-pypa/14657, but here's a quick outline. Currently, the logo as shown on Python Packaging Authority is just the PSF > Python logo and the word pypa written beside it (see > https://github.com/pypa). We could create something more unique that > identifies Python packaging tools. For reference here’s what rust is doing > Create a more rustic icon for Cargo: > https://github.com/rust-lang/cargo/issues/4446. > My idea would be to have a Python snake encircling a box and leave the > content of the box to be a stylized capital P. The P here would represent > both the language Python and also the P from the Packaging > group/team/authority (whichever we choose to go by). Furthermore, child > projects under PyPA could replace the box content with their own sub-logos, > e.g. the build tool could put a gear icon into it. Relevant to the discussion is also The Packaging Platypus - > https://discuss.python.org/t/the-packaging-platypus/1939. I find the > platypus great as an overall logo for Python packaging, but sadly it’s not > really reusable for packaging projects and doesn’t translate well as a > favicon either due to the lower pixel count available in there. Dustin Ingram said that the PyPA does home some funds via Tidelift and PSF to allocate for creating this. The vote is to see if we all agree that this is something we should do. The logistics of choosing the design and contractor will be done separately if this vote goes through. Thanks, Bernat

16 16

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

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

Brett Cannon as PEP Delegate for PEP 639
by Paul Moore 27 Jan '22

27 Jan '22

Brett has volunteered as PEP delegate for PEP 639 (Improving license clarity with better package metadata). The process says: """ If their self-nomination is accepted by the other PyPA core reviewers, the lead PyPI maintainer and the default PEP-Delegate for package distribution metadata PEPs, then they will have the authority to approve (or reject) that PEP. """ It's not 100% clear to me how we get that acceptance, so I'm posting here to give anyone who wants to, a chance to object. In the absence of any specific comment in the process, I'll give it a week and then if there's no objections, assume that Brett will be PEP delegate. If anyone thinks approving PEP delegate volunteers should be handled differently, please say so. I'm just guessing as to what's reasonable here :-) Paul

6 9

Vote: +1 to Mark PEP-660 final or -1 to keep it provisional
by Bernat Gabor 06 Jan '22

06 Jan '22

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bu… Stéphane Bidoul raised the question of whether we should mark PEP-660 (editable installs) final now or not. Me and Paul Moore have differing opinions on this so we're calling a vote of the members. - Reasons to mark it final as Stéphane said: *PEP 660 has now been implemented in pip, flit, enscons, hatchling, pdm, poetry (merged by not released).* - Reasons why I think we should not mark it final: *You’ll only find out what gaps the standard has once it’s widely used. IMHO enough is not a few backends that are overall not that often used adopts it. But enough should be when the majority of the projects using it adopt it (e.g. 80% of projects). Now I can see this by either setuptools implementing it or people moving away from using setuptools in time. Most projects that currently implement the standard don’t provide a generic build framework, as setuptools does, but instead only a subset so they don’t necessarily expose the current standards potential issues (think e.g. flit is restricting itself currently to purely toml configuration driven and avoids having a build step).* I'll start the voting, from my side it's -1, aka keep it provisional for now. All the best, Bernat

14 26

PyPA vote: specifications discussions on discuss.python.org
by Thomas Kluyver 27 Dec '21

27 Dec '21

Hi all, It came up recently that the specifications process page (https://www.pypa.io/en/latest/specifications/ ) requires discussions on the distutils-sig mailing list, but in practice most of our packaging related discussions occur on https://discuss.python.org/c/packaging/14 now, and distutils-sig is barely used any more. There is a PR to update the specifications page to refer to the Discourse forum: https://github.com/pypa/pypa.io/pull/80 I believe this requires a PyPA vote (PEP 609 says that votes are required for "changes to how the PyPA operates, including but not limited to changes to its specification and governance processes..."). We've effectively already made the change in practice by not forcing people to post on distutils-sig, but if we've written down a governance document, we ought to follow it. So, please vote on requiring discussion of new/changed specs on the packaging board of discuss.python.org, instead of distutils-sig. +1 from me. Thomas

17 17

Your vote required - accept flit within PyPA
by Thomas Kluyver 01 Dec '21

01 Dec '21

As the main maintainer of Flit (https://flit.readthedocs.io/ ), I would like the project to join the PyPA. There was a preliminary discussion on Discourse (https://discuss.python.org/t/should-flit-become-a-pypa-project/11854 ), and Paul Moore agreed to second my call for a vote. According to PEP 609, we'll hold a vote for 7 days, and require a 2/3 majority to accept the project. +1 from me (of course) Thanks, Thomas

25 28