CI: Remove `conda list` from sdist build causing failures
I think the purpose of this build is to see if the sdist is pip install-able in which case I'm not sure why we are setting up conda just to do a `conda list`. 
cc @lithomas1 I think the wheel test failures are expected (same thing is happening in your pyproject.toml PR) > cc @lithomas1 I think the wheel test failures are expected (same thing is happening in your pyproject.toml PR)

I'll take a look. BTW, long term, I'm thinking about replacing this workflow with the "Build sdist" workflow in the wheel builders, once we're fully ready there (just missing arm64, ideally we switch to the cibuildwheel wheel builders for the RC).

There's still some nice stuff in the current sdist workflow that's missing from it, though (testing oldest supported numpy IIRC). > I think the purpose of this build is to see if the sdist is pip install-able in which case I'm not sure why we are setting up conda just to do a `conda list`.

IIUC, the use of the conda env is to ensure that the sdist is installable in a clean env without anything else.

(When we built the sdist, we installed stuff like numpy and Cython.) Looks like we still have issues with numpy 1.24.x.

On main, we don't have failing CI yet since some other package is pinning numpy < 1.24. There is a failure in main related to this: https://github.com/pandas-dev/pandas/actions/runs/3947077782

The error doesn't make sense to me, `always_yes` is only defined once. If we decide to remove conda as proposed in this PR, that would fix the error. Or maybe the problem comes from installing conda after installing python using the github action. Maybe better to setup conda directly, and just create a new environment at the end to install the sdist on it.

It'd be nice to have this green before the release, but this seems pretty specific to the CI configuration, not a problem with the sdist, so if there are no objections, I think I'll move forward with the release, regardless of the failure.

CC: @pandas-dev/pandas-core #49857 It's a problem with the provision-with-micromamba Github Action. It should be fine to cut a release without this.

I remember this from when I was messing around with cirun. So it appears the `conda list` specifically was causing the "`always_yes`" failure here.

The environment isolation is a fair point to keep the conda environment here for now.

> BTW, long term, I'm thinking about replacing this workflow with the "Build sdist" workflow in the wheel builders, once we're fully ready there (just missing arm64, ideally we switch to the cibuildwheel wheel builders for the RC).

With this in mind, I suppose if this temporarily fixes the failures in the sdist build we can just remove this `conda list` for now Going to push this in as it allows the sdist jobs to pass on main and all this does is remove a `conda list` output, especially since this may be replace with a step in the wheel builder workflow