Packaging Summit 2020 - Potential topics for discussion

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.
2 Likes

Standardizing sdists

I literally dreamed last night that I had solved that problem, so if you all care about my sleep quality, we will solve this one. :wink:

2 Likes

Working towards a standardized lock file format

Last discussion

3 Likes

Filling in the project/library gap for PEPs

E.g. like what I did with packaging.tags (I will also mention I just started work on a proof-of-concept solution for the simple repository API).

2 Likes

Standardize on common metadata in packages in pyproject.toml

Initial research

3 Likes

Advisory

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.

1 Like

Helping people build wheels

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.

@brettcannon: https://github.com/regro/conda-press for the conda->wheel tool

On the wheel building front, explicitly inviting Joe Rickerby (creator of https://github.com/joerick/cibuildwheel ) would potentially be a good idea.

Python 2 support going forward

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.

1 Like

Packaging Python’s Standard Library

context: If Python started moving more code out of the stdlib and into PyPI packages, what technical mechanisms could packaging use to ease that transition?

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.

/cc @njs