Add run_constrained

[dcherian]

From https://github.com/pydata/xarray/blob/main/ci/requirements/min-all-deps.yml with only netcdf4, h5netcdf, zarr backends specified.

Closes https://github.com/pydata/xarray/issues/7467

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[dcherian]

@conda-forge-admin, please rerender

[jhamman]

To check my understanding of what this does, this will warn (or error?) when a user tries to install xarray into a environment where one of the listed optional dependencies is out of range from what is listed in run_constrained?

[ocefpaf]

@jhamman that will error out with a package conflict message. It is, in a way, the best way to control optional dependencies version.

[dcherian]

And when creating a new env, it'll ensure these minimum versions even if the env file doesn't list them?

[ocefpaf]

And when creating a new env, it'll ensure these minimum versions even if the env file doesn't list them?

Nope. The user must list the optional dependencies. The user can drop the min versions pin though, the solver will do te right thing and respect the run constraints in xarray.

[dcherian]

Right that's what I meant. Sorry for nbeing unclear.

The user lists all the packages they want; and the solver will respect xarray's run constraints. Sounds like a feature!

We should have a policy on what to list here though: https://github.com/pydata/xarray/issues/7573

Should Xarray limit iris for example? It seems like almost no one is converting xarray datasets to iris or vice versa.

[ocefpaf]

The user lists all the packages they want; and the solver will respect xarray's run constraints. Sounds like a feature!

Yeah. We, conda-forge, should probably add those automatically for python projects in our recipes via grayskull. The problem is that most Python packages use this so loosely that we will probably create packages that are too "rigid" to install rather than more stable solves.

TL;DR the xarray metadata is solid and that makes sense here. Doing that for all packages, not so much.

[hmaarrfk]

is pandas 2 safe?

[ocefpaf]

is pandas 2 safe?

For the xarray version in this PR? No. But if we are to merge this we would rebase and the latest version of xarray already pins pandas accordingly.

[jhamman]

closed by #93