Generalization of save_script_parameters #145

Activity

1. ehrenfeu

   assigned

   ehrenfeu

   and

   rohangirishrao

   on Apr 10, 2026
2. ehrenfeu

   added

   enhancementNew feature or requestNew feature or request

   unit testingA unit test should be createdA unit test should be created

   on Apr 10, 2026
3. ehrenfeu

   added the

   Feature

   issue type on Apr 10, 2026
4. ehrenfeu

   added this to IMCF-Fijion Apr 10, 2026
5. ehrenfeu

   moved this to Ready in IMCF-Fijion Apr 10, 2026
6. ehrenfeu

   added this to the 2.1.0 milestone on Apr 10, 2026
7. ehrenfeu commented on Apr 10, 2026

   

   ehrenfeu

   on Apr 10, 2026

   MemberAuthor

   More actions

   example2.py

   This should better be written as:

   #@ File(label="Input data", style="directory") INPUT_PATH
   
   from imcflibs.imagej.misc import save_script_parameters
   
   save_script_parameters(script_globals=globals(), location_param="INPUT_PATH")

   in order to prevent the impression an additional Script Parameter is required for this solution / approach.
   💡Hint: ➡️ it's not.

   Running this with INPUT_PATH=/data/project23 would give:

   Saved 1 script parameters to: /data/project23/example2_run-2026-04-10--14-18_params.txt
   
8. rohangirishrao commented on Sep 17, 2026

   

   rohangirishrao

   on Sep 17, 2026

   Last edited by ehrenfeu

   Contributor

   More actions

   (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.

   (1) Agreed, easy to implement 👍🏽

   (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.

   (2) I'm not so sure this is a super helpful way of doing this, as this assumes that the script parameter path name will be known - e.g. many scripts use RESULTS_DIR as the output path, which would require passing the this path anyway. The added complexity of reading through all parameters, parsing the output path, and then opening the file to write to might be a bit overkill, especially as there is no real consistency across scripts as to the naming of the output path. Of course, this might introduce that consistency..

   (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).

   (3) Same logic as above, linked to (2).

   (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.

   (4) Also makes a lot of sense, timestamp is easy, but the script name might be trickier. I think script_info.getLocation might do the trick.

   (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).

   (5) is mostly moot if we do not implement 2./3., as the results directory set by the user should always be writable? We can wrap it in a try/except for the writing and opening file part, so that it fails gracefully if there are permission or path issues.

   edited by @ehrenfeu to include the referenced sections for easier understanding
9. rohangirishrao commented on Sep 30, 2026

   

   rohangirishrao

   on Sep 30, 2026

   Contributor

   More actions

   This discussion should continue in PR #156 where some of the changes suggested have already been implemented!