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

UX: add information about missing optional dependencies as warnings and error messages in yt.load #4275

Merged
merged 2 commits into from
Sep 12, 2023

Conversation

neutrinoceros
Copy link
Member

@neutrinoceros neutrinoceros commented Dec 29, 2022

PR Summary

Fix #4274
For now I've only tested this manually but it should be relatively straightforward to add tests.

TODO:

  • tests
  • clean up redundant checks and warnings (warn_h5py and the likes) from _is_valid methods
  • implement early returns in _is_valid methods when requirements are missing
  • rebase

@neutrinoceros neutrinoceros added UX user-experience enhancement Making something better labels Dec 29, 2022
@neutrinoceros neutrinoceros force-pushed the ux_missing_load_reqs branch 3 times, most recently from 64e1df1 to 2a7e176 Compare December 29, 2022 13:58
@neutrinoceros neutrinoceros changed the title UX: add information about missing optional dependencies as warnings and error messsages in yt.load UX: add information about missing optional dependencies as warnings and error messsages in yt.load Dec 29, 2022
@neutrinoceros neutrinoceros added the deprecation deprecate features or remove deprecated ones label Dec 29, 2022
@neutrinoceros neutrinoceros force-pushed the ux_missing_load_reqs branch 5 times, most recently from e714947 to a236aef Compare December 30, 2022 13:16
@neutrinoceros neutrinoceros changed the title UX: add information about missing optional dependencies as warnings and error messsages in yt.load UX: add information about missing optional dependencies as warnings and error messages in yt.load Dec 30, 2022
@neutrinoceros neutrinoceros marked this pull request as ready for review December 30, 2022 14:46
@neutrinoceros neutrinoceros added this to the 4.2.0 milestone Dec 31, 2022
@neutrinoceros neutrinoceros added the code frontends Things related to specific frontends label Jan 30, 2023
@neutrinoceros neutrinoceros marked this pull request as draft March 23, 2023 16:54
@neutrinoceros neutrinoceros marked this pull request as ready for review April 4, 2023 10:29
@neutrinoceros neutrinoceros force-pushed the ux_missing_load_reqs branch 2 times, most recently from 7c672bf to 55015cb Compare April 14, 2023 17:40
Copy link
Contributor

@chrishavlin chrishavlin left a comment

Choose a reason for hiding this comment

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

I'd like to check out the branch and play around with this before hitting the approve button, but here are a few comments and questions in the mean time. Generally looks good to me though!

yt/data_objects/static_output.py Show resolved Hide resolved
yt/frontends/chombo/data_structures.py Show resolved Hide resolved
yt/frontends/enzo/data_structures.py Show resolved Hide resolved
yt/frontends/rockstar/data_structures.py Outdated Show resolved Hide resolved
yt/loaders.py Outdated Show resolved Hide resolved
@neutrinoceros
Copy link
Member Author

FYI @chrishavlin I just forced pushed again to resolve a conflict. I don't intend to touch this branch anymore for now so feel free to play around with it

@neutrinoceros
Copy link
Member Author

I would still be happy to see this in yt 4.2, but it can wait, and it doesn't seem worth blocking either, so I'll remove it from the milestone

@neutrinoceros neutrinoceros removed this from the 4.2.0 milestone May 3, 2023
@neutrinoceros
Copy link
Member Author

I'll actually go one step further and add the "do not merge" label since it contains new deprecation warnings that need to reflect the first version they appeared in, and it doesn't look like it's going to be 4.2

@neutrinoceros neutrinoceros added the do not merge this change should not be merged until later label May 4, 2023
@chrishavlin
Copy link
Contributor

Thanks for the ping! Should be able to get to this tomorrow!

chrishavlin
chrishavlin previously approved these changes Jul 20, 2023
Copy link
Contributor

@chrishavlin chrishavlin left a comment

Choose a reason for hiding this comment

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

Ok! had a chance to test this out locally and it's great. I noted one odd quirk with enzo, but this is good to go after the conflicts are resolved IMO.

def _is_valid(cls, filename: str, *args, **kwargs) -> bool:
return filename.endswith(".hierarchy") or os.path.exists(
f"{filename}.hierarchy"
)
Copy link
Contributor

@chrishavlin chrishavlin Jul 20, 2023

Choose a reason for hiding this comment

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

OK, odd quirk here! I just tried loading IsolatedGalaxy in a fresh environment with a minimal yt install (so no h5py), and you get:

>>> ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
<stdin>:1: UserWarning: This dataset appears to be of type EnzoDataset, but the following requirements are currently missing: h5py, libconf
Please verify your installation.
yt : [INFO     ] 2023-07-20 11:34:36,033 Parameters: current_time              = 0.0060000200028298
yt : [INFO     ] 2023-07-20 11:34:36,033 Parameters: domain_dimensions         = [32 32 32]
yt : [INFO     ] 2023-07-20 11:34:36,033 Parameters: domain_left_edge          = [0. 0. 0.]
yt : [INFO     ] 2023-07-20 11:34:36,034 Parameters: domain_right_edge         = [1. 1. 1.]
yt : [INFO     ] 2023-07-20 11:34:36,034 Parameters: cosmological_simulation   = 0

Based on the _is_valid here, the fact that the load appears to work (you actually get populated parameters!) would not be new to this PR , so it's actually quite helpful to have that UserWarning show up. But would it make sense to add an error here?

Initially I was gonna suggest adding

        if cls._missing_load_requirements():
            return False

like in the other updated _is_valid methods. But then that would print out the full list of h5py-dependent frontends that are possible. And here we actually know it's enzo.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the paradigm has always been that _is_valid methods are not allowed to throw errors as it would give each frontend the power to break all others. Maybe I'm not understanding your suggestion ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not suggesting to throw an error within the method.

Just saying that you could refactor this is_valid to return False if the dependencies are missing, regardless of the filename convention check that it does now. That would result in a unidentified datatype error right away rather than a partially functional ds.

Copy link
Contributor

@chrishavlin chrishavlin Jul 20, 2023

Choose a reason for hiding this comment

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

I'm just on the fence on whether it's better have a non functional ds but know that it's Enzo or an error right away and not know it's Enzo.

Copy link
Member Author

Choose a reason for hiding this comment

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

oh, I see. The behaviour you're pointing to is not intended ! I must have been testing this with yt.load_sample("IsolatedGalaxy") instead, which behaves differently. Your suggestion makes both loaders behave similarly, which is great, but we also loose the warning... I'll switch to draft while I try to think of a better solution.

Copy link
Member Author

Choose a reason for hiding this comment

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

ah, I see now that I replied in a hurry: as you already pointed, the behaviour of the Enzo frontend is weird on the main branch, and my patch only adds a warning to it (which is the point).
I'd prefer to keep this PR's scope limited to adding warnings and details to existing errors, rather than actively changing frontends' behaviour, just to keep things as tidy as possible. But I would merge your suggestion as a standalone patch ! WDYT ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ya, that sounds good to me!

Copy link
Contributor

@chrishavlin chrishavlin Jul 21, 2023

Choose a reason for hiding this comment

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

Mostly just wanted to bring up this behavior --- even without a follow-up patch, having the warning now is better than the behavior on main!

@neutrinoceros
Copy link
Member Author

conflicts resolved

@neutrinoceros neutrinoceros force-pushed the ux_missing_load_reqs branch 2 times, most recently from 060a62c to 175fb09 Compare July 20, 2023 17:35
@neutrinoceros neutrinoceros marked this pull request as draft July 20, 2023 17:43
@neutrinoceros neutrinoceros marked this pull request as ready for review July 21, 2023 08:47
@neutrinoceros
Copy link
Member Author

this is good to go after the conflicts are resolved IMO.

@chrishavlin ? 👼🏻

chrishavlin
chrishavlin previously approved these changes Sep 12, 2023
@neutrinoceros
Copy link
Member Author

Ah, I forgot to update the deprecation messages (which is why I used the "do not merge" label). I'll do it now and hopefully we can merge then.

@neutrinoceros neutrinoceros removed the do not merge this change should not be merged until later label Sep 12, 2023
@neutrinoceros
Copy link
Member Author

@chrishavlin sorry to ping you again. This is now ready to go !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code frontends Things related to specific frontends deprecation deprecate features or remove deprecated ones enhancement Making something better UX user-experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

UX: add hints to YTUnidentifiedDataType
3 participants