I don’t think there’s a topic for this yet, so I thought I’d start one. One item from me.
Helping users to test PyPA tool releases before using them in production
We’ve had a few recent issues with new releases hitting users’ production CI and generating significant issues, with little or no warning. How do we avoid this? We already suggest that users test new releases before going live with them, but that’s hard for them to do. Some thoughts:
Release beta versions/release candidates. But how do we get people to use them?
A lot of the problem is likely due to the fact that workflows like tox, or pip install, or virtualenv pull in the latest version of all tools. It’s basically fairly difficult to pin versions on your production CI. What can we do to make the defaults less risky, and to make pinning the natural option, rather than a complicated choice that no-one bothers with until they’ve been thoroughly burned?
Do tools like pip, setuptools, virtualenv, tox need to publish “known stable” versions? Can we do this without making continuous releases or calendar-based releases impossible? How does this impact the need to make newer functionality (like PEP 517, or TUF) available to users as quickly as possible?
Do we need funded/commercial support for something like this? Volunteer-based release management shouldn’t be expected to provide 1-hour turnaround on fixes for release issues. No matter how many people use that project.
We have not decided yet on how we’re going to determine the topics for the summit this year. We may want to use a different process from last year, so I have explicitly not “opened” the call for proposals about this yet.
Anyone can feel free to continue to use this thread to discuss topic proposals, but I don’t think we’ll want to use it as the official topic submission mechanism - we may want, for example, for topic voting to be presented in a randomized order, and we may ask for more information than last time.
Work with conda-forge to help get their tooling to stamp out conda and wheel recipes
I can’t remember the name of their tool off the top of my head.
Provide help using e.g. GitHub Actions to build wheels
Assuming GH Actions, we could develop actions to help with the wheel building and then any templates as necessary to help with this where an action wouldn’t work.
IMO, we should come up with good metrics that would help make it clearer where we want to be, before we’d drop Python 2 support in packaging tooling.
For pip, I’m already finding it frustrating to work with Python 2 – we’re blocked on at least 2 improvements because of dependencies needing a whole bunch of Python 2 specific code.
I think, ideally, someone should propose discussing this topic in the Language Summit too; it’d probably make sense to spend more in-person discussion time on something this drastic! I think there would be a decent overlap in the audience of both these summits.
Reminder: The topic proposal form closes on 7th March, 11:59pm AoE, which is ~24 hours from now. If you have a topic that you want to propose for discussion at the Packaging Summit, please make sure to fill the form at http://bit.ly/python-packaging-summit-2020-topics.
