Skip to content

Get product versions from dependency json#3313

Merged
tech3371 merged 8 commits into
IMAP-Science-Operations-Center:new_version_workfrom
vineetbansal:vb/issue3266
Jun 24, 2026
Merged

Get product versions from dependency json#3313
tech3371 merged 8 commits into
IMAP-Science-Operations-Center:new_version_workfrom
vineetbansal:vb/issue3266

Conversation

@vineetbansal

@vineetbansal vineetbansal commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

Closes issue #3266

Change Summary

The dependency string in imap_cli is now assumed to supply the desired version major/minor for each product, for example:

{
            "dependency": [
                {
                    "type": "ancillary",
                    "files": [
                        "imap_mag_l1b-cal_20250101_v001.cdf",
                        "imap_mag_l1b-cal_20250103_20250104_v002.cdf"
                    ]
                },
                {
                    "type": "science",
                    "files": [
                        "imap_idex_l2_sci_20240312_v000.cdf",
                        "imap_idex_l2_sci_20240312_v001.cdf"
                    ]
                }
            ],
            "version": {
                "cal": {"major_version": 2, "minor_version": 1}
            }
        }

The keys in the version key of the json are assumed to be the last part of the Logical_source of the xarray dataset (which has _ separated strings). This is the same assumption as the current code, which uses Logical_source to determine the descriptor:

cdf/utils.py - write_cdf function:

instrument, data_level, descriptor = dataset.attrs["Logical_source"].split("_")[1:]

Note the following behavior that allows gradual adoption and testing.

  1. The --version argument in imap_cli is still supported, but is optional.
  2. If provided, the --version argument is used to determine the descriptor versions of any descriptors that do not appear in the dependency string above. If the dependency string provides the version for a descriptor, it is used.
  3. The old format of the dependency string is still supported - in that case, the version provided by --version is used as a fallback for all descriptors.

I'm hoping that 1+2+3 will allow testing of this code quickly with dagster on a small set of products to see if expected descriptors are generated with expected version numbers. I can take off one or more or all of these 3 behaviors, either in this PR, or in future PRs.

One assumption I'm making here:

  • The Data_version attribute of the CDF is populated to be exactly the version (for example, v017.0042). This is because something in the in-memory CDF needs to keep the version around as the dataset object is passed from one function to another, before it is written to disk. This could be any attribute really (or could be additional arguments we introduce between functions), but Data_version seems like the logical choice.

However, if the one-off migration script that SDC has written populates this attribute a different way, then things will not be consistent between the one-off script and imap_processing. If a different format of Data_version is assumed by the migration script, then we need to make the corresponding change here.

EDIT: As per @tech3371, in commit #2ccc939 in this PR, the Data_version attribute populated in the CDF is the version string without the v prefix, for example, 007.0042.

@vineetbansal vineetbansal changed the title Vb/issue3266 Get product versions from dependency json Jun 19, 2026
@vineetbansal vineetbansal changed the title Get product versions from dependency json WIP: Get product versions from dependency json Jun 19, 2026
@vineetbansal vineetbansal changed the title WIP: Get product versions from dependency json Get product versions from dependency json Jun 19, 2026

@tech3371 tech3371 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Minor comments but the code changes looks good to me. Looks like upload already skips uploading if file already exists.

Comment thread imap_processing/cli.py Outdated
Comment thread imap_processing/cli.py
Comment thread imap_processing/tests/test_cli.py Outdated
Comment thread imap_processing/tests/test_cli.py Outdated
Comment thread imap_processing/cli.py Outdated
Comment thread imap_processing/cli.py Outdated
Comment thread imap_processing/cli.py Outdated
Comment thread imap_processing/tests/test_cli.py Outdated
Comment thread imap_processing/cli.py

@lacoak21 lacoak21 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM!

@bryan-harter bryan-harter left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good!

@tech3371 tech3371 changed the base branch from dev to new_version_work June 24, 2026 18:14
@tech3371 tech3371 merged commit d10c481 into IMAP-Science-Operations-Center:new_version_work Jun 24, 2026
14 checks passed
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.

4 participants