-
Notifications
You must be signed in to change notification settings - Fork 7
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -52,6 +52,7 @@ dependencies: | |
|
||
# Core scientific python stack | ||
- cython==0.29.32 # optimization, C API access | ||
- flox~=0.9.7 # optimization, xarray operations | ||
- hypothesis==6.58.0 # needed by numpy testing tools | ||
- networkx==2.8.8 | ||
- numba~=0.58.1 # high-performance numerics | ||
|
@@ -62,7 +63,7 @@ dependencies: | |
- scipy==1.9.3 | ||
- statsmodels==0.13.5 | ||
- sympy~=1.12 | ||
- xarray>=2023.05.0 | ||
- xarray>=2024.05.0 | ||
|
||
# Visualization packages | ||
- bokeh~=3.2.2 | ||
|
@@ -80,15 +81,16 @@ dependencies: | |
- geopandas~=0.13.2 | ||
- pygmt~=0.10.0 | ||
- rasterio~=1.3 | ||
- rioxarray~=0.14.1 | ||
- xarray-datatree~=0.0.12 | ||
- rioxarray~=0.15.5 | ||
- xarray-datatree~=0.0.14 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. true! time to drop it here |
||
|
||
# File formats and file management, download, dataset caching | ||
- h5py~=3.8 | ||
- hdf5~=1.14 | ||
- h5netcdf==1.1.0 | ||
- h5netcdf~=1.3.0 | ||
- nco~=5.1.6 | ||
- pooch==1.6.0 | ||
- zarr~=2.18 | ||
|
||
# Cloud access tools and libraries | ||
- awscli~=1.27.76 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
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 thatconda-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).