Approvals/merging/building responsibilities

[Dr-Irv]

For @twoertwein and @bashtage

I've been doing PRs without having them reviewed, but given that both of you are on the pandas core team and are making great contributions here, I'm wondering if I should now do my PRs and have either of you review/approve them, along with merging them in upon approval.

Can the two of you let me know if you would like to help out in that way?

Second question is whether either or both of you want to help out with making new releases and pushing them to pypi as well as becoming conda feedstock maintainers/approvals. Then those responsibilities don't only fall in my lap.

[twoertwein]

I'm happy to review and merge your PRs. Since there are some goal differences between the type annotations in pandas and pandas-stubs, I do not feel comfortable merging PRs that are not from you @Dr-Irv or not approved by you (I think I align more with the goals of the pandas annotations).

So far, I don't have any experience with publishing releases. If you need help, I might be able to help with pypi, but I'm reluctant to help with conda (I haven't used conda in ages and don't intent to use it in the future - poetry is sooo much better). It would be cool, if conda would just fallback on pypi (pandas-stub has no dependencies on non-python packages: there isn't really a need for conda).

[Dr-Irv]

Publishing is pretty easy. Once you publish to pypi, there is a bot on conda-feedstock that picks up that the version has changed, auto-creates a PR, and then you just approve it, and you're done.

I will write a documentation page on the publication procedure.

[bashtage]

I'm happy to review, but it would help me if I was requested.

Have you thought about storing the wheel as an artifact on the build where the version is the date the wheel is built? This would make releasing as simple as uploading the already existing wheel.

[Dr-Irv]

Have you thought about storing the wheel as an artifact on the build where the version is the date the wheel is built? This would make releasing as simple as uploading the already existing wheel.

I've been doing the build and publish steps together so I'm not sure of the value of storing the wheel somewhere, since it does get pushed to pypi and the wheels are all there.

[Dr-Irv]

I've documented the release procedure here: https://github.com/pandas-dev/pandas-stubs/blob/main/docs/release_procedure.md

@twoertwein if you're willing to share that responsibility with me, I can add you as a maintainer on pypi.

[twoertwein]

I created an account at pypi.org.

I assume the steps could be slightly simplified to:

rm dist/*
poetry publish --build --username $PYPI_USERNAME --password $PYPI_PASSWORD
git commit -a -m "Version a.b.c.yymmdd"
git push upstream main
git tag va.b.c.yymmdd
git push upstream --tags

[Dr-Irv]

I created an account at pypi.org.

I've invited you.

I did try poetry publish in the past, and it failed. Also, wasn't clear that poetry publish was also creating (and then publishing) the gzipped tar file of the source.

The project is now deemed "critical", which means that you have to have 2FA set up, and I just received an email that in the future, an API token will be required to do the uploads. I will put that on my list of things to look into.

[twoertwein]

Thank you!

The project is now deemed "critical",

Already linked my yubikeys with pypi. I was surprised that signing packages is not common/required on pypi (but it is probably also difficult to know which public keys to trust).

[twoertwein]

I think you can downgrade me to a maintainer: "Can upload releases for a package." should be sufficient, or?

[Dr-Irv]

I think you can downgrade me to a maintainer: "Can upload releases for a package." should be sufficient, or?

OK, I did that.