xscen 0.9.1 incompatible with xclim 0.53.1

[SarahG-579462]

Generic Issue

• xscen version: 0.9.1
• Python version: python 3.11.10
• Operating System: Linux (conda)

Description

Conda happily installs xclim == 0.53.1 with xscen == 0.9.1, which is incompatible. There should be a xclim max version.

A solution would be to push a patch release 0.9.2 with the maximum compatible xclim set, and no other changes.

Specific error:
backend-dev-1 | ImportError: cannot import name 'convert_calendar' from 'xclim.core.calendar' (/opt/conda/envs/backend/lib/python3.11/site-packages/xclim/core/calendar.py)

[RondeauG]

Do you absolutely need v0.9.x ? We sorted those issues since v0.10.x.

[SarahG-579462]

I know -- It ended up not being needed by installing xscen == 0.10.1, but by default when including xscen, xclim and xarray without any pins, conda seems to prioritize the latest version of xarray (2024.10.0), which is incompatible with v0.10.x (xarray required: >=2023.11.0,!=2024.10.0)

[RondeauG]

@Zeitsperre Any easy way to fix the pins in v0.9.1? If we release a v0.9.2, would it be detected as the latest release?

[Zeitsperre]

I don't have much experience with patching older versions. I'm not certain how best to do it. I'll see if I can read up on it.

[Zeitsperre]

The issue I can see here is that we don't tend to place upper pins on any of the xarray entries in most of our projects. As such, If we set a new pin to an existing release (which is possible using twine set-metadata dist/your-package-1.2.3.tar.gz --metadata Requires-Dist="xarray>=1.2.3,<4.5.6"), this will simply prioritize the next older unpinned version.

My suggestion if we never want to have to deal with this is to set upper pins on everything and ensure that our release schedule(s) are often enough that users don't complain (I think this might already be the case).

Otherwise, for versions that we really don't want people using, we can make use of PyPI's yank and conda-forge's --mark broken.

[Zeitsperre]

Further reading tells me that you can't modify the dependency matrix of an already-published version (though you can modify a built package using twine, which is definitely interesting).

The only option is to yank or --mark broken the packages and upload new ones. Given that already have newer versions superseding them... Not sure if it's worth the effort.

[RondeauG]

Given that we'd need to modify every release older than v0.10.0, this is probably too much work for the benefit...