"utils" import problem

[alice-crafford]

There's a small issue in the RAIL evaluation demo with the first cell of imports:
"from utils import ... " does't work, & as discussed with Alex & Prof. Mandelbaum, it should be either rail.core.utils or rail.evaluation.utils .

[eacharles]

I think there is a chance it is actually a utils module that was in the examples area.On Jun 30, 2023, at 7:46 PM, alice-crafford ***@***.***> wrote: There's a small issue in the RAIL evaluation demo with the first cell of imports: "from utils import ... " does't work, & as discussed with Alex & Prof. Mandelbaum, it should be either rail.core.utils or rail.evaluation.utils . —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aimalz]

To fill in some context, there are several modules in src/rail/* called "utils", which isn't a great practice in general and can make it confusing for users to troubleshoot errors and import issues. The fix will be for us to make sure those modules have distinct and descriptive names.

[eacharles]

Can you provide a list?

…

On Jul 7, 2023, at 1:22 PM, Alex Malz ***@***.***> wrote: To fill in some context, there are several modules in src/rail/* called "utils", which isn't a great practice in general and can make it confusing for users to troubleshoot errors and import issues. The fix will be for us to make sure those modules have distinct and descriptive names. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRIGIWP7TUQNWYLP7FS4WLXPBVZ3ANCNFSM6AAAAAAZ2GBDIY>. You are receiving this because you commented.

[aimalz]

• rail/examples/evaluation_examples/utils.py (This seems to have a lot of overlap with rail_base/src/rail/evaluation/metrics/pointestimates.py so could maybe be trimmed down to just be rail/examples/evaluation_examples/dc1_shortcut.py or something like that.)
• rail_base/src/rail/evaluation/utils.py (I think it would be fair to call this rail_base/src/rail/evaluation/aggregators.py since it's just about combining outputs of closely related metrics into single objects so stages can write them to a single file, yes? It would not be unreasonable to use something like that to reconcile wanting the freedom to not calculate every single metric and wanting multiple metrics written to a single output file.)
• rail_base/src/rail/core/utils.py (I think it would be appropriate to call this rail_base/src/rail/core/path_utils.py since that's what's in it, but that would have implications for the next one.)
• rail_bpz/src/rail/bpz/utils.py (This lives in one of those inconsistent paths I mentioned in Inconsistent import paths for sibling classes across rail* repos #23 BTW, but based on its contents, it could be moved to rail_bpz/src/rail/estimation/algos/_bpz_utils.py. However, unless the namespace magic interprets two files of the same name at the same path in different packages to be the union of their contents, if we expect different standalone packages to have to define something like this, then the above proposal should instead be rail_base/src/rail/core/path_utils/find_rail_file.py and this one should be moved to rail_bpz/src/rail/core/path_utils/bpz_path.py.)
• rail_base/src/rail/core/utilStages.py (This is good but should be changed to rail_base/src/rail/core/util_stages.py for consistency.)
• rail_base/src/rail/core/algo_utils.py (Not problematic, although I still don't understand why this and the files at the paths it specifies aren't in rail_base/tests because it only pertains to functionality needed for unit tests.)
• rail_gpz_v1/src/rail/estimation/algos/_gpz_util.py (I induced this one but can rename it rail_gpz_v1/src/rail/estimation/algos/_gpz_utils.py for consistency with the others.)
• rail_astro_tools/src/rail/tools/utilPhotometry.py (This lives in one of those inconsistent paths I mentioned in Inconsistent import paths for sibling classes across rail* repos #23 and would be renamed to rail_astro_tools/src/rail/tools/photometry_utils.py for consistency.)

[eacharles]

rail/examples/evaluation_examples/utils.py -> This stuff is only used by the evaluation demo notebook. I think the answer here is to clean up that notebooks and either get stuff from somewhere else, or just add it to the notebook. If we have other notebooks that start needed some of this stuff, we can think about where it belongs in the wider RAIL ecosystem. This should be it's own issue.

rail_base/src/rail/evaluation/utils.py -> rail_base/src/rail/evaluation/aggregators.py Ok, sure. That makes it sound like a new type of stages, which could be confusing. "stats_groups" or "data_structures" might avoid that confusion. This should be it's own issue.

rail_base/src/rail/core/utils.py and rail_base/src/rail/bpz/utils.py: changing these would be very disruptive. I think we should leave them. In all the examples we do from rail.bpz.utils import RAIL_BPZ_DIR or from rail.core.utils import find_rail_file`, which works fine.

rail_base/src/rail/core/utilStages.py -> rail_base/src/rail/core/util_stages.py: this might require changing a number of notebooks pipelines. If we want to do it, it should be it's own issue.

rail_base/src/rail/core/algo_utils.py: this is here so that other packages can use it for tests, if it were in rail_base/tests that would not be possible. I think we should leave it here.

rail_gpz_v1/src/rail/estimation/algos/_gpz_util.py -> rail_gpz_v1/src/rail/estimation/algos/_gpz_utils.py: This is local to gpz. It would be easy to do.

rail_astro_tools/src/rail/tools/utilPhotometry.py -> rail_astro_tools/src/rail/tools/photometry_utils.py: this might require changing a number of notebooks pipelines. If we want to do it, it should be it's own issue.

[eacharles]

Ok, I've made new issues for the things that ones that aren't particularly disruptive.

[eacharles]

Can we close this now?

[aimalz]

Thanks @eacharles for working through this while I was out! Please tell me if my understanding of the current status is correct:

• rail/examples/evaluation_examples/utils.py sounds like it's no problem to rename (or merge into the one notebook that uses it, although it might be a lot of function definitions to put into a demo); it makes sense for this to be a part of Refactor Evaluator/MetricEvaluator #14 since the one demo that uses it will undergo some refactoring for that anyway, but it could just as easily be a separate issue if you prefer
• rail_base/src/rail/evaluation/utils.py -> rail_base/src/rail/evaluation/stats_groups.py is completed
• rail_base/src/rail/core/utils.py and rail_base/src/rail/bpz/utils.py seem tangled up with Inconsistent import paths for sibling classes across rail* repos #23 so would be better discussed there
• rail_base/src/rail/core/utilStages.py -> rail_base/src/rail/core/util_stages.py is completed
• rail_base/src/rail/core/algo_utils.py needs no change -- thanks for the explanation!
• rail_gpz_v1/src/rail/estimation/algos/_gpz_util.py -> rail_gpz_v1/src/rail/estimation/algos/_gpz_utils.py can move forward with a fresh issue
• rail_astro_tools/src/rail/tools/utilPhotometry.py -> rail_astro_tools/src/rail/tools/photometry_utils.py is completed

Is that accurate? If so, I'll fix the rail_gpz_v1 one and close this issue.

[eacharles]

yes, that is accurate.