Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update xarray and friends #113

Merged
merged 4 commits into from
May 20, 2024
Merged

Update xarray and friends #113

merged 4 commits into from
May 20, 2024

Conversation

scottyhq
Copy link
Contributor

There a many great new xarray features from the last year. This bumps to the latest version as well as optional dependencies

@scottyhq
Copy link
Contributor Author

/condalock

Copy link

Binder 👈 Test this PR on Binder

@scottyhq scottyhq requested a review from weiji14 May 16, 2024 19:30
environment.yml Outdated
Comment on lines 84 to 85
- rioxarray~=0.15.5
- xarray-datatree~=0.0.14
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know whether the migration of datatree into xarray is good enough yet to just drop xarray-datatree? I saw in the changelog at https://github.com/pydata/xarray/releases/tag/v2024.05.0 which said that most of the code has been migrated, but not sure how feature complete things are.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true! time to drop it here

@scottyhq
Copy link
Contributor Author

/condalock

environment.yml Outdated
@@ -62,7 +63,7 @@ dependencies:
- scipy==1.9.3
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could not solve for environment specs
The following packages are incompatible
├─ scipy 1.9.3  is requested and can be installed;
└─ xarray >=2024.05.0  is not installable because it requires
   └─ scipy >=1.10 , which conflicts with any installable versions previously reported.

Situations like these make me question the pinning strategy here, wouldn't it be better to unpin everything and just use the lockfile to keep track of exact versions over time?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we were slowly trying to move towards >= or ~= pinning per #46, but could revisit the topic. I do think that conda-lock has matured quite a bit now, and we could consider just unpinning everything and rely on the unified lockfile (once I get the time to update #14).

@scottyhq
Copy link
Contributor Author

/condalock

@scottyhq scottyhq merged commit a006351 into main May 20, 2024
1 check passed
@scottyhq scottyhq deleted the xarray-bump branch May 20, 2024 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants