You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this PR on the aiida-quantumespresso plugin, we had to deprecate some exit codes since they were erroneously checking if certain resources were set (which should have probably been checked in a validator to begin with). This raised the question on what the deprecation pathway should be for exit codes.
As @sphuber explains in the issue here, the integer exit_status and string exit_message are both stored in the attributes of the process node, so even if an exit code is removed or repurposed, existing nodes will still reflect the original message through things like verdi process status/list etc. However, repurposing is not advisable, since this would mean that queries would find both the deprecated and new exit codes. So removing them might also be a bad idea, since at some point we might forget that this exit code has already been used previously and it would be repurposed. Then again, without a deprecation pathway they might start to accumulate over time and get in the way.
So the question is how to deal with deprecating exit codes? Do we store a list of "blocked" exit codes on a process class that a developer cannot use, so we can store deprecated exit codes in a succinct manner? Or is there a better solution?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In this PR on the
aiida-quantumespresso
plugin, we had to deprecate some exit codes since they were erroneously checking if certain resources were set (which should have probably been checked in a validator to begin with). This raised the question on what the deprecation pathway should be for exit codes.As @sphuber explains in the issue here, the integer
exit_status
and stringexit_message
are both stored in the attributes of the process node, so even if an exit code is removed or repurposed, existing nodes will still reflect the original message through things like verdi process status/list etc. However, repurposing is not advisable, since this would mean that queries would find both the deprecated and new exit codes. So removing them might also be a bad idea, since at some point we might forget that this exit code has already been used previously and it would be repurposed. Then again, without a deprecation pathway they might start to accumulate over time and get in the way.So the question is how to deal with deprecating exit codes? Do we store a list of "blocked" exit codes on a process class that a developer cannot use, so we can store deprecated exit codes in a succinct manner? Or is there a better solution?
Beta Was this translation helpful? Give feedback.
All reactions