Skip to content

Fix for misc.save_script_parameters (Issue #136)#140

Merged
ehrenfeu merged 46 commits intoimcf:develfrom
rohangirishrao:save-script-params
Apr 10, 2026
Merged

Fix for misc.save_script_parameters (Issue #136)#140
ehrenfeu merged 46 commits intoimcf:develfrom
rohangirishrao:save-script-params

Conversation

@rohangirishrao
Copy link
Copy Markdown
Contributor

The function now accepts globals() as a parameter - this is a workaround as calling globals() from the method did not work, see #136.

ehrenfeu and others added 3 commits January 23, 2026 12:44
Attempt to fix the problem in a new branch, see imcf#136 for details.
This is necessary as calling globals from inside the method lead to no variables from the call time.
@rohangirishrao rohangirishrao changed the title Fix for m (Issue #136) Fix for misc.save_script_parameters (Issue #136) Mar 25, 2026
@codecov
Copy link
Copy Markdown

codecov bot commented Mar 25, 2026

Codecov Report

βœ… All modified and coverable lines are covered by tests.
βœ… Project coverage is 32%. Comparing base (376ceb7) to head (a4cb525).
⚠️ Report is 47 commits behind head on devel.

Additional details and impacted files
@@         Coverage Diff          @@
##           devel   #140   +/-   ##
====================================
+ Coverage     30%    32%   +2%     
====================================
  Files         25     25           
  Lines       1748   1782   +34     
====================================
+ Hits         526    563   +37     
+ Misses      1222   1219    -3     

β˜” View full report in Codecov by Sentry.
πŸ“’ Have feedback on the report? Share it here.

πŸš€ New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ehrenfeu ehrenfeu self-requested a review March 25, 2026 21:27
@ehrenfeu ehrenfeu added the enhancement New feature or request label Mar 25, 2026
@ehrenfeu ehrenfeu added this to the 2.0.0 milestone Mar 25, 2026
@ehrenfeu ehrenfeu linked an issue Mar 25, 2026 that may be closed by this pull request
@ehrenfeu ehrenfeu moved this to In review in IMCF-Fiji Mar 25, 2026
@rohangirishrao
Copy link
Copy Markdown
Contributor Author

Is there anything to be done for the codecov failing? There is no way to really test this part

@@ -115,13 +115,15 @@ def _is_password_style(item):
monkeypatch.setattr(imcflibs.imagej.misc, "_is_password_style", _is_password_style)

script_module = ScriptModule(
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.

@rohangirishrao let's discuss together what makes sense in terms of testing once you're back!

🚧 We also need to verify if the modified code in save_script_parameters() still works in ImageJ / Jython as expected / intended! 🚧

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

TODO: it is better to keep them split, as using the same output_dir from script params for example, in all methods is easier. The name of the file can be changed separately from the path, we have other methods where we pass the output_dir so for consistency, I think it's best to keep both.

_is_password_style() looks great, thanks for that! I think the tests are good, we could test for the save_file_name being correct, but maybe that's not so necessary. We can take a look together tomorrow, and I'll see if I can test it in Fiji till then.

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.

  1. Regarding the two separate parameters: understood, that's what my (very faint) memory told me anyway, hence the question. ➑️ βœ…
  2. The saved file is already re-read by the test, so that should be fine. Regarding testing in Fiji, I have now updated the corresponding file in tests/interactive-imagej/ (and renamed it from test_save_params.md to save-script-parameters.py), which also lead to the discovery of a bug that got fixed in e8140ed. Let's have another look together tomorrow, but I believe we should be fine here.

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.

it is better to keep them split, as using the same output_dir from script params for example, in all methods is easier. The name of the file can be changed separately from the path, we have other methods where we pass the output_dir so for consistency, I think it's best to keep both.

Done (added a comment to explain the intent) in 8b208cb βœ…

Comment on lines +852 to +861
# TODO: discuss if this approach is fine within Fiji/Jython
try:
val = inputs.get(key)
if not val: # required for testing in CPython
raise KeyError("failure looking up value for '%s'" % key)
f.write("%s: %s\n" % (key, str(val)))
saved += 1
except:
log.warning("Unable to fetch value for parameter: %s", key)
pass
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.

🚧 This needs to be validated (cf. comment in tests)! 🚧

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.

The code in the state as shown here would ignore / exclude boolean parameters with a value of False - as mentioned in the previous comment, this is now fixed in e8140ed.

ehrenfeu added 9 commits April 8, 2026 16:53
The previous "if not val" also triggers if the parameter is a boolean
that has the value "False" and therefore wrongly excludes those.
Checking for "is None" only triggers if the .get() call fails and
returns its default value (None).
The workflow described in TESTING.md states to drag and drop the script
onto Fiji, so for the time being let's stick to that
@ehrenfeu
Copy link
Copy Markdown
Member

ehrenfeu commented Apr 10, 2026

Actually... While doing all of this a few more ideas for this function popped πŸ’‘ up:

  1. It would be nice if the function were to automagically determine whether the parameters should be saved or not. Then it could simply always be called from our scripts and do its service. A reasonable πŸ€” approach would be to have an empty default value for the target location by using destination="" and skip parameter saving if it's not defined.

  2. Instead of supplying the saving location explicitly in parameter destination, we could modify it such that the location is defined within the Script Parameters (see illustration example below) using a default parameter name (e.g. OUTPUT_PATH or similar) and only have an optional parameter for save_script_parameters that allows to specify which Script Parameter contains the saving location if it differs from the standard.

  3. To achieve this, processing βš™οΈ of the Script Parameters in save_script_parameters would need to be modified such that it works through the items obtained via script_globals and assembles a list of things πŸ“‘ to be saved while determining the saving location πŸ’Ύ at the same time - only using open(out_path, "w") as f: after all Script Parameters have been processed (as only then out_path would be known).

  4. We should consider to construct the file name used to save the parameters and values automatically, e.g. following this pattern: <calling_script_name>_run-<timestamp>_params.txt - this would allow for saving the parameters at each run without having to worry (too much) about overwriting previously saved ones. For hints on how to identify the name of the calling script, this SO thread might contain useful ideas - 🚨 careful though, it's pretty old and might not work the same way in ImageJ-Jython! ☝🏼The .py suffix should be stripped from the pattern.

  5. In case saving the parameters in the OUTPUT_PATH location suggested above fails (location might be read-only, ...), falling back to e.g. the user's home directory would be nice (plus issuing a ⚠️ warning message obviously).

example1.py

#@ File(label="Input data", style="directory") INPUT_PATH
#@ File(label="Path for results", style="directory") OUTPUT_PATH

from imcflibs.imagej.misc import save_script_parameters

save_script_parameters(script_globals=globals())

Running the above with OUTPUT_PATH=/data/project23/results would result in this:

Saved 2 script parameters to: /data/project23/results/example1_run-2026-04-10--10-41_params.txt

example2.py

This illustrates the option of using a different Script Parameter to define where the parameters should be saved:

#@ File(label="Input data", style="directory") INPUT_PATH
#@ File(label="Path for results", style="directory") OUTPUT_PATH
#@ File(label="Path to store parameters", style="directory") PARAMS_PATH

from imcflibs.imagej.misc import save_script_parameters

save_script_parameters(script_globals=globals(), location_param="PARAMS_PATH")

Running this with PARAMS_PATH=/data/project23/runs would give:

Saved 3 script parameters to: /data/project23/runs/example2_run-2026-04-10--10-50_params.txt

🀯 😳

Now, obviously - these are a lot of changes, and they definitely qualify for a separate issue. In my opinion, the main question (apart from discussing the stuff mentioned above) is whether to have this for the 2.0.0 milestone or if this should go into a subsequent release (🚨 having a high probability of becoming a breaking change and hence requiring a new major release...)?

@ehrenfeu ehrenfeu merged commit 0be22b3 into imcf:devel Apr 10, 2026
6 checks passed
@github-project-automation github-project-automation bot moved this from In review to Done in IMCF-Fiji Apr 10, 2026
@ehrenfeu
Copy link
Copy Markdown
Member

After discussing today we decided to:

  • merge this PR into devel - it's about fixing the broken function, which is done βœ…
  • move πŸ”œ the suggested changes to a new issue (or multiple ones) and then decide there πŸ”€ about the milestone question

@rohangirishrao rohangirishrao deleted the save-script-params branch April 10, 2026 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Issue accessing globals() from library

2 participants