Whether an environment variable in a config field will get properly expanded depends a lot on how that path is actually evaluated – it's certainly not guaranteed. I'd recommend testing it with your existing setup first.

Much later EDIT: a meaningless objection, since it's your code that decides how the config field is evaluated. Apologies for the noise!

I actually missed the last part of the meeting. That's why I'm wondering about the discussed storage options for the model packages.

I can think of these options – and indeed I don't think we need to limit ourselves to only one:
1- local storage: model-packages that are local to the meas_TransiNet repository and are always fetched with it (e.g. the dummy model). We can probably access them just using a relative path :think:

2- neighbor git data-repository: I suppose these can also be accessed using a relative path, assuming the repository is always cloned into its default location.

3- butler repository: to be discussed.

I guess we are now waiting for John Parejko to get a pre-confirmation re. feasibility of these implementations.

I don't have the full context here, but I read Ian's summary as saying that local storage is out (I fully agree), neighbor git repository is in (accessed via eups environment variable, not relative path), and Butler repository seems unlikely (since this is more like code than data).

The relevant model package is now being stored in the neighboring package (rbClassify_data). Here's the relevant PR:
https://github.com/lsst-dm/rbClassifier_data/pull/1

I think this addresses the purpose of this ticket. Please let me know if something is missing.

Am I correct in assuming that finishing DM-37478 will make this issue obsolete? If not, what is the new scope?