-
Notifications
You must be signed in to change notification settings - Fork 40
Python 3.13 and 3.14 Support #3383
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
base: dev
Are you sure you want to change the base?
Changes from all commits
a8b7ea3
5cd1992
f1e0cca
232a50b
3a2e087
1d89a41
df131ff
3c06931
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 |
|---|---|---|
| @@ -1,3 +1,3 @@ | ||
| # These version placeholders will be replaced later during substitution. | ||
| __version__ = "1.0.35.post11.dev0+ed24bc01" | ||
| __version_tuple__ = (1, 0, 35, "post11", "dev0", "ed24bc01") | ||
| __version__ = "1.0.36.post5.dev0+4650530a" | ||
| __version_tuple__ = (1, 0, 36, "post5", "dev0", "4650530a") |
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -78,6 +78,7 @@ num_events: | |||
| FIELDNAM: Number of Events | ||||
| FILLVAL: *uint16_fillval | ||||
| FORMAT: I5 | ||||
| LABLAXIS: Number of Events | ||||
|
Contributor
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. By CDF metadata standard, metadata should only have one, either LABLAXIS or LABL_PTR_1. Because of that, we didn't add LABLAXIS when there is LABL_PTR_1. At one point, I went through CDF metadata requirement and documented what applies to us here https://imap-processing.readthedocs.io/en/latest/cdf-metadata/cdf_requirements.html. If SAMMI is throwing error or etc, that could be because it doesn't check to that detail yet still. Please apply this same suggestion to other places
Suggested change
To get around that issue, we have been setting |
||||
| LABL_PTR_1: priority_label | ||||
| SCALETYP: linear | ||||
| UNITS: " " | ||||
|
|
||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,6 +10,7 @@ | |
|
|
||
| import imap_data_access | ||
| import numpy as np | ||
| import pandas as pd | ||
| import xarray as xr | ||
| from cdflib.logging import logger as cdflib_logger | ||
| from cdflib.xarray import cdf_to_xarray, xarray_to_cdf | ||
|
|
@@ -23,6 +24,43 @@ | |
| logger = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| def _cdf_compatible_dataset(dataset: xr.Dataset) -> xr.Dataset: | ||
| """Return a shallow copy whose extension arrays are NumPy-backed. | ||
|
|
||
| ``cdflib`` expects array-valued variables to be backed by NumPy arrays. In | ||
| particular, it cannot serialize the string extension arrays that pandas 3 | ||
| uses by default. Converting at the CDF boundary keeps the in-memory dataset | ||
| unchanged and also supports explicitly created extension arrays on pandas 2. | ||
|
|
||
| Parameters | ||
| ---------- | ||
| dataset : xarray.Dataset | ||
| Dataset to prepare for serialization by ``cdflib``. | ||
|
|
||
| Returns | ||
| ------- | ||
| xarray.Dataset | ||
| Shallow copy with extension-array variables converted to NumPy arrays. | ||
| """ | ||
| converted = dataset.copy(deep=False) | ||
| for name, variable in dataset.variables.items(): | ||
| if not isinstance(variable.data, pd.api.extensions.ExtensionArray): | ||
| continue | ||
|
|
||
| numpy_variable = xr.Variable( | ||
| variable.dims, | ||
| variable.data.to_numpy(copy=True), | ||
| attrs=variable.attrs, | ||
| ) | ||
| numpy_variable.encoding = variable.encoding.copy() | ||
| if name in dataset.coords: | ||
| converted = converted.assign_coords({name: numpy_variable}) | ||
| else: | ||
| converted[name] = numpy_variable | ||
|
|
||
| return converted | ||
|
|
||
|
|
||
| def load_cdf( | ||
| file_path: Path | str, remove_xarray_attrs: bool = True, **kwargs: dict | ||
| ) -> xr.Dataset: | ||
|
|
@@ -185,7 +223,11 @@ def write_cdf( | |
| # strict ISTP compliance | ||
| logger.info("Disabling cdflib ISTP logging for level 1 data products") | ||
| cdflib_logger.setLevel(logging.ERROR) | ||
| xarray_to_cdf(dataset, str(file_path), **extra_cdf_kwargs) | ||
| xarray_to_cdf( | ||
| _cdf_compatible_dataset(dataset), | ||
|
Contributor
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. is this needed to support python version 13 and 14? |
||
| str(file_path), | ||
| **extra_cdf_kwargs, | ||
| ) | ||
| finally: | ||
| # Set back to the previous logging level | ||
| cdflib_logger.setLevel(prev_cdflib_level) | ||
|
|
||
|
Contributor
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. @laspsandoval tagging to make sure these I-ALiRT changes looks good. |
|
Contributor
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. may not need this test |
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.
@leowerneck - it may be better to have a CI workflow parallel to the current testing but with
poetry lock --regenerateso it tests stuff with floating dependencies, so we can catch these things early on. Perhapscontinue-on-error: trueso it doesn't alarm PR submitters?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.
@vineetbansal - I think your suggestion makes a lot of sense. What are your thoughts on running the floating-dependency tests against the oldest and newest supported Python versions? I think that could be a good way to catch errors that a single job with
poetry lock --regeneratemight overlook. I also like thecontinue-on-error: truesuggestion.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.
yes that's a good idea. I think I've indeed seen in other projects that you can get away with just testing on the oldest and newest supported pythons to bracket a floating dependency issue, reducing CI time in the process.