Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Python 3.9 trove classifier to the metadata #2421

Merged
merged 2 commits into from Oct 17, 2020

Conversation

webknjaz
Copy link
Member

@webknjaz webknjaz commented Oct 12, 2020

Summary of changes

$sbj.

Pull Request Checklist

  • Changes have tests
  • News fragment added in changelog.d. See documentation for details

hugovk
hugovk approved these changes Oct 12, 2020
changelog.d/2421.misc.rst Outdated Show resolved Hide resolved
s/trove/Trove/

Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
@webknjaz
Copy link
Member Author

webknjaz commented Oct 16, 2020

@jaraco mind labeling this PR as hacktoberfest-accepted?

@jaraco
Copy link
Member

jaraco commented Oct 17, 2020

So much toil. Now that Python releases are yearly, we probably should look to reduce the number of steps/tweaks that have to happen with each release.

@jaraco jaraco merged commit 97253c8 into pypa:master Oct 17, 2020
4 checks passed
@jaraco
Copy link
Member

jaraco commented Oct 17, 2020

By the way, thanks for taking on these thankless tasks.

@webknjaz
Copy link
Member Author

webknjaz commented Oct 17, 2020

You're welcome :)

@webknjaz
Copy link
Member Author

webknjaz commented Oct 17, 2020

we probably should look to reduce the number of steps/tweaks that have to happen with each release.

How about a GHA job that would get a target version via GH UI inputs, update the changelog + commit it + tag that + build dists + publish them and push the commit+tag back to master: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
This could be done in a more or less atomic fashion and also open a PR for visibility. Although, the PR itself wouldn't generate CI runs because of the GITHUB_TOKEN event propagation limitations so it'd have to run the tests in the same job if necessary.

@jaraco
Copy link
Member

jaraco commented Oct 17, 2020

Oh, I wasn't talking about Setuptools releases, but about Python releases. For Setuptools releases, the workflow is pretty straightforward for me:

$ tox -e finalize
$ git push

But the release of Python 3.9 has seen several actions necessary for this project (and presumably every other project with a similar configuration):

  • at some point when pre-releases are available, configure the pre-releases of that version (3.9b versus nightly) on some or all CI engines
    • if the pre-release versions aren't supported by the CI engine, also build custom code to make that version of Python available
  • only after trove classifiers are published, add the new version to the trove classifiers
  • after the release is final, update the techniques from the beta version to the final version (for each CI engine) and remove custom code for running pre-release versions.

At about the same cadence, there's the deprecation of older versions, which requires additional toil, including:

  • update the minimum version supported in requires_python/Python-Requires.

Ideally, it would be nice to:

  • Automatically declare support for some common configurations of Python versions (stable, pre-release, sunset)
  • Have the CI configurations and metadata automatically transition in/out.

I've managed some of this toil in the jaraco/skeleton project by:

  • Not supplying Python version specific Trove classifiers (turns out almost no one reads these), and rely on the Python-Requires as the designator.
  • Testing on a small but fairly complete list of platforms and Python versions managed centrally.

@webknjaz
Copy link
Member Author

webknjaz commented Oct 17, 2020

Oh, so I recently learned about the composite actions they seem to be a perfect fit for this task: https://docs.github.com/en/free-pro-team@latest/actions/creating-actions/creating-a-composite-run-steps-action.
I've even considered creating one under PyPA just like the action for uploading to PyPI. Although, I haven't had time to try it out myself.
The idea would be to have a curated workflow as a building block for other projects to use. It would have some matrix pre-setup and probably some inputs for tweaking things. And the steps would be pretty much standard tox invocations. This would at least address the CI side of the problem.

Stuff that requires updating the files in repos would be harder to implement because not all files are easily parseable. I guess, using setup.cfg could make things easier.

One other thing that may be useful would be some sort of a GitHub App based linting/recommendation system. It could alert projects to update their metadata when it's impossible to set up fully automatic workflows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants