Skip to content

feat: config workflow for wavelength / anode type #169

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

Merged
merged 8 commits into from
Apr 21, 2025

Conversation

yucongalicechen
Copy link
Collaborator

closes #160
@sbillinge ready for review

Copy link

codecov bot commented Feb 24, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.31%. Comparing base (bd71eda) to head (b19d44a).
Report is 9 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
+ Coverage   99.19%   99.31%   +0.11%     
==========================================
  Files           5        5              
  Lines         249      292      +43     
==========================================
+ Hits          247      290      +43     
  Misses          2        2              
Files with missing lines Coverage Δ
tests/conftest.py 100.00% <ø> (ø)
tests/test_tools.py 98.84% <100.00%> (+0.38%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@sbillinge sbillinge left a comment

Choose a reason for hiding this comment

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

nice work. Please see inline

@@ -159,6 +160,33 @@ def set_input_lists(args):
return args


def _load_wavelength_from_config_file(args):
"""Load wavelength and anode type from config files.
It takes cli inputs first, and local config, and then global config.
Copy link
Contributor

Choose a reason for hiding this comment

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

there should be a blank line before this.

Also, I suggest to make this not private.

# C3: anode type provided, expect to return args unchanged
(["--anode-type", "Mo"], {"wavelength": None, "anode_type": "Mo"}),
# C4: both wavelength and anode type provided,
# expect to return args unchanged
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this what we want? I think it should be either wavelength or anode_type. If both are provided raise an exception.

# C3: anode type provided, expect to return args unchanged
(["--anode-type", "Mo"], {"wavelength": None, "anode_type": "Mo"}),
# C4: both wavelength and anode type provided,
# expect to return args unchanged
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that the tests should be the same here, as they are, but we then need to modify the last test in both places.

Also maybe mention in the preamble that the home config file has wavelength of 0.3 and the local config has wavelength of 0.6 to make the test easier to read.

A thought occurred to me that maybe having both wavelength and anode_type specified is tested elsewhere and you do want to return both values here but have it fail in a test elsewhere, but i fthat is the case, say it explicitly in the comment about the test.

"inputs, expected",
[
# Test when no config files exist,
# expect to return args without modification.
Copy link
Contributor

Choose a reason for hiding this comment

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

here don't we expect it to run the "create config" workflow if no wavelength/anode_type is specified?

Copy link
Collaborator Author

@yucongalicechen yucongalicechen Mar 15, 2025

Choose a reason for hiding this comment

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

Yeah I think the idea is that this function just updates the correct args. The error will be reported when we set the wavelength etc. I will add a comment here.
For the create config workflow, I think we discussed that we might not want to make it too complicated for users?

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure what we discussed. We created to the "create config workflow" to be as intuitive to use as possible. After that it should just be a choice in apps (a) use it (b) don't use it, so I am not sure I understand your statement about making things not complicated for users.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Getting back to this - I just remembered what we discussed. I think it's a bit complicated to create config workflow here because we want user to enter either wavelength or anode type but not both. So it might be better if we just let the user decide whether to put wavelength/anode type in the config file manyally. Maybe we can load it from args to the config file automatically, if that make things easier?

Copy link
Contributor

Choose a reason for hiding this comment

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

right, I see. Yes, we could just put it in the docs. In general, we want this behavior set up by say a lab manager (llike a beamline scientist) so that every user who runs the machine doesn't have to enter the value manually. So a complicated command line way of capturing it is probably not warranted. I agree. But let's put it in the docs to merge this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sounds good, I added a task in issue #158 to add instructions in docs. I updated the codes to address the comments above.

@yucongalicechen yucongalicechen mentioned this pull request Apr 20, 2025
1 task
"wavelength" in global_config or "anode_type" in global_config
)
if not local_has_data and not global_has_data:
print(
Copy link
Collaborator Author

@yucongalicechen yucongalicechen Apr 20, 2025

Choose a reason for hiding this comment

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

Print instructions for manually adding wavelength to config file when it's not found (I reused wording from the create_config function in diffpy.utils)

# otherwise update args with values from the home config file
# (wavelength=0.3, no anode type).
# This test only checks loading behavior,
# not value validation (which is handled by `set_wavelength`).
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added home config info about wavelength/anodetype and clarified that this function only checks loading behavior

@@ -279,13 +406,13 @@ def test_set_wavelength(inputs, expected):
( # C3: invalid anode type
# expect error asking to specify a valid anode type
["--anode-type", "invalid"],
f"Anode type not recognized. "
f"Anode type 'invalid' not recognized. "
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Updated error message slightly to be more informative

@yucongalicechen
Copy link
Collaborator Author

Okay, I did some cleanup and updates to match the current muD cli behavior - ready to be review now @sbillinge

Copy link
Contributor

@sbillinge sbillinge left a comment

Choose a reason for hiding this comment

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

very nicely done. Let's user test now and make sure users like the workflow.

config = local_config if local_has_data else global_config
if config:
args.wavelength = args.wavelength or config.get("wavelength")
args.anode_type = args.anode_type or config.get("anode_type")
Copy link
Contributor

Choose a reason for hiding this comment

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

this is all very nicely done. I like the coding style very much. Very readable.

@sbillinge sbillinge merged commit 9618ab0 into diffpy:main Apr 21, 2025
5 checks passed
@yucongalicechen yucongalicechen deleted the wavelength-config branch April 21, 2025 15:17
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.

feat: add config workflow for wavelength
2 participants