Deprecation during install with latest version of `pip`

[WilliamJamieson]

When installing towncrier in Python 3.11 using pip 23.0.1, I got the warning:

DEPRECATION: click-default-group is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change.
A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559

This appears to be an issue with how click-default-group handles getting itself installed.

[webknjaz]

FTR pip install --no-cache --no-deps click-default-group crashes with the modern pip for me. Only pip < 22 is able to build it from the sdist. Missing wheels are quite problematic.

Hey @sublee, @davidism and @untitaker, this package being unmaintained, causes problems with some essential ecosystem projects, like Towncrier. It has to be re-packaged and published with wheels to PyPI. Would you be willing to let somebody with relevant experience fix this and assist with publishing? Maybe, consider moving the project to Jazzband for shared maintenance?

[davidism]

I don't have access to this. click-contrib is @untitaker's, although we're happy to accept them into @pallets-eco for community maintenance.

[untitaker]

@davidism i have invited you to be full owner of this github organization. click-contrib predates pallets, I believe it should be the same thing eventually

[davidism]

@webknjaz were you volunteering to be added as a maintainer to this project? I currently do not have the capacity to maintain more projects myself, but I'm happy to add known community members or active contributors, and answer maintainer-related questions.

@untitaker I'll also need access to all the projects' PyPI, ReadTheDocs, etc. I think you can add the "pallets" org on PyPI instead of individual users.

[untitaker]

Unfortunately both of those are exclusively owned by @sublee. click-contrib was primarily intended to make discoverability of click extensions easier, there was not enough consolidation in release process to actually allow for continued maintenance

[davidism]

OK, so newly added maintainers will need to start reaching out to original owners, or PyPI and ReadTheDocs support, to get access.

[webknjaz]

@davidism this project is not particularly interesting to me functionally, but being a transitive dependency, it did affect me. So if I can help with fixing packaging and publishing to PyPI, I will. Past that, though, I wouldn't be maintaining it. Feel free to invite me here if you're fine with this limited amount of help.

P.S. To allow the current project maintainers to make the transfer, you'll have to invite them to the pallets PyPI org with at least Manager access level. Alternatively, they'll need to invite you (or anybody with sufficient org access), giving you an Owner privilege.

[sublee]

I've just re-packaged click-default-group to follow the modern standard in Python packaging. Sorry for making a trouble due to lack of maintenance.

[webknjaz]

@sublee would you be open to setting up an automated GitHub Actions publishing pipeline for other people to be able to make releases from this repository?

This spring, it became possible to have secretless publishing as documented here: https://docs.pypi.org/trusted-publishers/. Most people end up using my pypi-publish GitHub Action for this: https://github.com/marketplace/actions/pypi-publish#trusted-publishing. To configure, you'd need to set up trust on the PyPI side, select a publishing workflow name (I usually go for ci-cd.yml) and enter pypi as an environment name (it can be any other name, but I prefer this one) in the trust form. The rest can then be configured by the people with access to this repository.

[untitaker]

I would suggest to add me or @davidism as owner on pypi to help out with immediate maintenance needs like this one. if there is a need to automate and consolidate release processes in click-contrib I would rather that this effort is spent once across all repos instead of individual solutions. The problem is not just lack of automation, even if that automation existed in each repo I wouldn't know how to use it if differs between repos.

[webknjaz]

I also noticed there's a few other packaging-related issues that might need to be address or closed if solved.

[sublee]

@webknjaz I accept your suggestion and just configured to use the pypi-publish action.

@untitaker As you suggested, I invited you and @davidism on PyPI as an owner.

[webknjaz]

@sublee I see you set up GHA to publish to TestPyPI. In order to publish to the actual "production" PyPI, remove the with: section completely.

Also, make sure to set up trust on PyPI, not TestPyPI.

Another thing I noticed if that you build the package in the publishing job. I recommend having it in a separate job that doesn't have the OIDC privilege. You'd pass the dists between jobs using the official upload-artifact and download-artifact actions.

And for people with the repo access, I recommend adding the approval requirement for the pypi env in the repo settings.

[sublee]

@webknjaz Thanks for the great tips. My configuration was not perfect. 😅 All of your advice has been applied.

[webknjaz]

Looks good now. Hopefully, the repo admins implemented their part of the config :)