Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-628

Do not persist ineffectual deprecated Config fields


    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:


      With the implementation of RFC-607, we have a way of deprecating Config fields, which is very useful. However, there is an unintended side-effect in the current implementation.

      Currently, the implementation is straightforward, simply adding deprecated= to the config Field. Then a python warning is thrown when you try to set the deprecated config field on the command line or in a config .py file.

      When you run a task with an updated config that properly avoids the deprecated field so that no warning is thrown, the task will still persist the config with all fields – including the deprecated field. Helpfully, the persisted config will have the deprecation warning in the comment. However, if you use this persisted config file as an input to a new run, then you suddenly get a deprecation warning. This is unexpected because the user never explicitly set the deprecated config parameter.

      Unfortunately, a fully general solution to this problem is difficult because of the ambiguity of whether a deprecated Field is now completely ignored under all circumstances, or will be ignored if a new replacement Field is set.

      This RFC proposes a simple solution that will likely cover most cases. Specifically, if a config Field is deprecated and is equal to the default value (or otherwise unset in the case of optional config Field s) then it will not be persisted.


          Issue Links



              • Assignee:
                erykoff Eli Rykoff
                erykoff Eli Rykoff
                Eli Rykoff, Jim Bosch, John Parejko, Krzysztof Findeisen
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created:
                  Planned End:

                  Summary Panel