1.1.0 Release / ACCESS-NRI COSIMA Training on 21/02/2025

[charles-turner-1]

We would like to release 1.1.0 in time for the ACCESS-NRI COSIMA Training on 21/02/2025.

The crucial feature to include for this release is #317, and probably searchable coordinate variables, but I've added some extra features that I think it would be good to include in the release - if possible & we have time to do so.

@marc-white @chrisb13 @anton-seaice @dougiesquire @rbeucher

Features to include:

• Individual expts #317
• More robust, atomized catalog build #316
• Documentation for individual experiment catalogues #326
• Suggested documentation tweaks based on COSIMA user feedback #195
• intake-esm build with discoverable coordinates - added in Cannot open coordinate variables from Intake-ESM datastores intake/intake-esm#660, awaiting release.
• Listing variables with intake catalog COSIMA/cosima-recipes#481

Optional?

• Telemetry #311

Deferred

• [DATA REQUEST] Add AUS2200 datasets #319

Post-Release:

• Make_Your_Own_Intake_Datastore tutorial doesn't work with panantarctic / regional mom6 COSIMA/cosima-recipes#480
• New Catalog build with coordinate variables

Is there anything I've missed that should be added/people feel should be removed?

[marc-white]

I'll take on the data addition #319 once Gadi comes back up.

[marc-white]

Also, I think #195 could be a handy addition if this is a pre-workshop release.

[charles-turner-1]

Bit of Friday afternoon cleanup:

• All the definite features are in.
• Anderson has merged the new version of intake-esm-feedstock, so we can bump the intake-esm & intake versions in the conda env @rbeucher.
• Post release checklist still needs doing.

I still haven't worked out conda feedstocks to my satisfaction & I'd like to spend some time working on ESMValCore <=> intake integration, so I think maybe we leave the telemetry for this release?

[rbeucher]

Great 👍

[rbeucher]

So I can't do that because the current access-nri-intake package has a strong dependency on intake==0.7.0 while intake-esm 2025.2.3 has dependency intake>=2.0.0....

[charles-turner-1]

So I can't do that because the current access-nri-intake package has a strong dependency on intake==0.7.0 while intake-esm 2025.2.3 has dependency intake>=2.0.0....

Here?

Must be somewhere else, no?

[rbeucher]

[charles-turner-1]

Weird.. we updated the dependencies in pyproject.toml in #232 and #233, so long before the 1.0.0 release.

There must be some other dependencies file buried somewhere - presumably for conda - see below.

$ cd ~/scratch/            
$ python -m venv venv             
$ source venv/bin/activate.fish           
$ pip install access-nri-intake             
Collecting access-nri-intake
  Downloading access_nri_intake-1.0.0-py3-none-any.whl.metadata (3.4 kB)
Collecting cftime (from access-nri-intake)
  Using cached cftime-1.6.4.post1-cp312-cp312-macosx_11_0_arm64.whl.metadata (8.7 kB)
Collecting ecgtools>=2023.7.13 (from access-nri-intake)
  Using cached ecgtools-2024.7.31-py3-none-any.whl.metadata (3.9 kB)
Collecting intake>=0.7.0 (from access-nri-intake)
  Using cached intake-2.0.8-py3-none-any.whl.metadata (2.4 kB)
...
$ pip list | rg 'intake'  
access_nri_intake         1.0.0
intake                    2.0.8
intake_dataframe_catalog  0.3
intake-esm                2025.2.3

I'll dive into it and see what I can work out - presumably this is something dumb and hopefully fairly trivial 🤞 .

[charles-turner-1]

Aha - only updated the meta.yaml last week in #323 to remove the hard pin on 0.7.0, so post 1.0.0.

I guess we'll need to release 1.1.0 before we can rebuild the conda environment then?

[rbeucher]

Should we replace the conda package for 1.0.0?

[charles-turner-1]

Yeah, I think so.

I've had issues with trying to overwrite releases on PyPI before - not sure if this also an issue with conda/you've ever ran into this? I suspect if we branch from wherever the head was at 1.0.0, apply #323 to that and then release that as a 1.0.1, that might be a tad simpler?

[charles-turner-1]

I've set up a v1.0.1 branch here, just gonna run the E2E tests and all being well I'll push the v1.0.1 tag.

[rbeucher]

I have updated the package on conda but now I have the same issue with intake-dataframe-catalog. Let me know what you think is best, we can edit the packages dependencies or wait for a new release

[charles-turner-1]

I'm just dealing with some (potentially) related issues - end to end tests are now failing due to yaml.safe_load() not having a constructor registered for PosixPath objects - I'm pretty sure this will have originated somewhere around #306 or #271 where we moved paths being passed around as strings to Path objects. I had an e2e run pass a week or two ago, so I'm not quite sure why it's only become an issue recently but we'll see.

Either way, the issue is in intake-dataframe-catalog, so I'll make my fixes there & then make a PR with all the fixes & the updated meta.yaml once I'm confident on there.