CI: Remove redundant sdist workflow

[mroeschke]

AFAICT: The sdist workflow was essentially similar as the build_sdist job in the wheels workflow except it didn't test the sdist cc @lithomas1

[lithomas1]

I think the reason that I didn't remove this yet was because we don't have a way of testing that the oldest supported numpy works (on all Python versions).

Not sure if this testing is too relevant now though.

Agreed this would be nice to remove though.

[mroeschke]

It seems the workflow never really tested pandas with the lowest oldest supported, just that pd.show_versions worked. It doesn't look like we have any runtime checks for this either.

But as long as we have oldest-supported-numpy shouldn't we be okay?

[datapythonista]

This seems reasonable.

Not sure the context when the job was created, but testing that pandas can be imported when installed with an sdist with an old numpy installed seems redundant and somehow cumbersome, given that we run all the test suite with the old numpy and we test the sdist.

Somehow unrelated. Would it make sense to run the tests on the same jobs we build the wheels? From the release point of view, feels like it'd make sense to test on the CI what's really being released.

Also, how do you feel about copying the recipe from feedstock to this repo, and having a CI job to build the conda package? That would be nice to avoid having to update the recipe during the release process.

[mroeschke]

Somehow unrelated. Would it make sense to run the tests on the same jobs we build the wheels? From the release point of view, feels like it'd make sense to test on the CI what's really being released.

I would be +1 to this. It would be great to the have the CI more representative of testing pandas from what users install. We should probably still have a job that tests that pandas can be installed from source and pass the test suite.

Also, how do you feel about copying the recipe from feedstock to this repo, and having a CI job to build the conda package? That would be nice to avoid having to update the recipe during the release process.

I guess I wouldn't be opposed to this, but IIRC the conda forge build is still triggered from the Github release being created?

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout 2.0.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 f990ab01ed1991a5ed8be9bc08135fdf78794050

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #52794: CI: Remove redundant sdist workflow'

4. Push to a named branch:

git push YOURFORK 2.0.x:auto-backport-of-pr-52794-on-2.0.x

5. Create a PR against branch 2.0.x, I would have named this PR:

"Backport PR #52794 on branch 2.0.x (CI: Remove redundant sdist workflow)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

[datapythonista]

I guess I wouldn't be opposed to this, but IIRC the conda forge build is still triggered from the Github release being created?

That was broken for few releases, but for the last one the PR was automatically created. But even if the conda-forge bot creates the PR, the CI for the will fail if changes are needed to the recipe.

The idea is that if for example you're adding a new required dependency, the conda-forge recipe needs to be updated. Now, we discover this in the middle of the release. Having a CI build in the pandas repo itself that builds the conda package would make the CI fail in the PR where the dependency is added, and the copy of the recipe in the pandas repo will have to be updated. This way, in the release we already have the working recipe that we just need to copy.