Repository navigation
Deprecate MMAR APIs and disable load_from_mmar #9179
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
8923552
3754d3b
e344df1
734dcca
d43c76d
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 |
|---|---|---|
|
|
@@ -20,19 +20,31 @@ | |
| import os | ||
| from typing import Any | ||
|
|
||
| from monai.utils.deprecate_utils import deprecated | ||
|
|
||
| __all__ = ["MODEL_DESC", "RemoteMMARKeys"] | ||
|
|
||
|
|
||
| @deprecated( | ||
| since="1.7.0", | ||
| removed="1.9.0", | ||
| msg_suffix="NVIDIA Clara MMAR support is deprecated. Please use MONAI Bundles instead.", | ||
| ) | ||
| class RemoteMMARKeys: | ||
|
Collaborator
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. RemoteMMARKeys is a constants namespace, so this decorator only fires on instantiation, which nothing in the code base does. Verified at this head commit with version_val set to 1.7.0: attribute access such as RemoteMMARKeys.NAME emits no warning; with 1.9.0, attribute access still returns the constants while instantiating raises DeprecatedError. MODEL_DESC has the same property. The new test covers the instantiation path, so it does not exercise what users would actually observe. If the intent is simply that this module disappears at 1.9.0 then that is reasonable, but a sentence to that effect in the deprecation note (or a test on the attribute-access path) would make the schedule meaningful.
Contributor
Author
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. Good point, thanks. The intent is that the constants and |
||
| """ | ||
| Data keys used for loading MMAR. | ||
| ID must uniquely define an MMAR. | ||
|
|
||
| .. deprecated:: 1.7.0 | ||
| NVIDIA Clara MMAR support will be removed in version 1.9.0. Use MONAI Bundles instead. | ||
| Reading these constants or ``MODEL_DESC`` does not emit a warning; both will be removed | ||
| with the MMAR module in version 1.9.0. | ||
| """ | ||
|
|
||
| ID = "id" # unique MMAR | ||
| NAME = "name" # MMAR name for readability | ||
| URL = "url" # remote location of the MMAR, see also: `monai.apps.mmars.mmars._get_ngc_url` | ||
| DOC = "doc" # documentation page of the remote model, see also: `monai.apps.mmars.mmars._get_ngc_doc_url` | ||
| DOC = "doc" # documentation page of the remote model | ||
| FILE_TYPE = "file_type" # type of the compressed MMAR | ||
| HASH_TYPE = "hash_type" # hashing method for the compressed MMAR | ||
| HASH_VAL = "hash_val" # hashing value for the compressed MMAR | ||
|
|
||
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.
One deprecation ends up being reported twice here. download_mmar is decorated, and for a string item it delegates to get_model_spec, which carries the same decorator, so on 1.7.0 a single call such as download_mmar("clara_pt_prostate_mri_segmentation_1", mmar_dir=".", api=False) emits two FutureWarnings, one of them attributed to get_model_spec rather than to the function the caller invoked. Confirmed at this head commit by re-executing the module with version_val set to 1.7.0 and recording warnings: that call produced two FutureWarnings. Routing the internal lookup through a private undecorated helper would make a public call warn exactly once.
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.
Do we just suppress the warning for the call to
get_model_spec? The alternative is move the body ofget_model_specinto an auxiliary undecorated function which it anddownload_mmarcall.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.
Thanks both. I went with the helper approach: the lookup now lives in a private
_get_model_specthatget_model_specanddownload_mmarboth call, so a public call warns once. I chose it over suppression becausewarnings.catch_warningschanges global warning state and isn't thread-safe. I added a test with a string model ID that expects exactly one warning (734dcca), and the docstring sections CodeRabbit asked for (d43c76d). Prepared with help from Claude and Codex (taggedAssisted-byin the commits).