Done except for obs_decam (since I don't yet know where to find the official repo for that). Edits are in tickets/DM-3630. Tested by running the Jenkins CI system and by manually running some HSC data through processCcd.py. Now to find a reviewer. I think the main thing to check for is missing instances of "root" in the converted config files (especially if they have the standard type test near the top).

I am reviewing now.
(Still have electricity)

Review:

Double check the following two files:

• ctrl_execute:etc/configs/lsst_config.py
• ctrl_platform_lsst:etc/config/execConfig.py

In pex_config:python/lsst/pex/config/config.py, the docs in loadFromStream() and load() methods in class Config() confused me a bit. The docs say the override file should edit a config named 'root', but the variable name is now 'config' in the file (even though it is named root in the method).

Everything else looks good. I'm editing obs_decam now as the last component.

This must not be merged until notice has been provided to all users.

Were there any instances of config in a configuration file before the change?

Are there any users of the current stack who are likely to have old config override files (HSC does, but that's a different matter)? Before making a release I agree that we need to make sure that users know about incompatible changes.

I assume that no backwards-compatibility was provided, although I'd have thought it was pretty easy [this may be based on a naïve view of pex_config].

It's not just when we release, but as soon as it goes to master, anyone who might be using master needs to know.

To answer Paul Price: I did not find any instances of "config" used as a variable inside config override files. That means in theory we could continue to support root for backwards compatibility, while also supporting config. Doing just that much is trivial, but not adequate. To do it right we need to warn users when they load an outdated config override file, and I have not figured out how to do that.

My inclination is to make a hard break. Converting config override files is easy.

I agree about a hard break (though it may be controversial). I was more worried about breaking things if someone was using config inside an override file already.

I found a safe way to support root:

• try loading the override file using "configure"
• if that raises NameError and the exception contains "root" (which is what happens if the file uses "root" instead of "config) then print a warning and try again, using "root".

This seems safe to me. It will work with files that use "root" and contain a variable named "config". Similarly it will work for files that use "config" but contain a variable named "root. The only way I think it can cause problems is if the config override file has an error and the resulting message is a NameError whose message contains "root". In that case I would expect it to try loading again with "root" (which it should not do) and to fail with a confusing error message.

I think we should remove this backwards compatibility code at some point, but give people some time to update their personal config files first.

Yusra AlSayyad Thank you very much for the review.

Regarding the two config files: you were right that I had corrupted them. The value of defaultRoot should be "/lsst/DC3root" in both cases.

Regarding pex_config:python/lsst/pex/config/config.py I agree that the documentation is confusing. I took a cleanup pass on all doc strings for the Config object. I hope it is clearer now. (Field still needs such a pass, but I found enough bits that I didn't understand that I decided to leave it alone.)