Replies: 3 comments
-
I think this would be infinitely more convenient. I also think there is nothing preventing one from defining a setting like this, since settings can be nested and we already have examples of settings like that, for instance the It would just be necessary for somebody to go through and redefine the settings in such a way, perhaps using migrations to allow the old versions to still work, and then to update all places in the code where the relevant settings are queried. That sounds like a lot of work, but I think it is possible using only the machinery we have available now. |
Beta Was this translation helpful? Give feedback.
-
I really do like organization. But this seems like the biggest possible API break we could think up in ARMI. Or at least, has the potential to lead to Big PRs in every repo that uses ARMI. So, backwards compatibility would be my primary concern here. For instance, basically every ARMI plugin registers settings and uses settings. So it would be a LOT of work if we change either of those workflows. Similarly, I think our Settings could be renamed to be better. But that would require 100 PRs, and wouldn't yield much other than niceness. So my same concern lingers there. I am in favor of organization in all things though. |
Beta Was this translation helpful? Give feedback.
-
@john-science If we were able to ensure backwards capability, I think it would be worth exploring. Though without a doubt, it would be a huge lift and require significant planning. That said, I think the long-term benefits for ease of use at least merit consideration and some discussion. But you're 100% right, this would just ultimately result in niceness and not really advance the capabilities of ARMI. I think the biggest offenders that I've come across are when settings that are very specific to a run type get left behind and end up in other runs (e.g., snapshot settings in standard runs or vice-versa). But since those settings aren't used, they are just ignored and left around. It can lead to settings files becoming a bit messy and a potentially convoluted, in my opinion. |
Beta Was this translation helpful? Give feedback.
-
Hey all - I had a thought while reviewing the new tight coupling settings ( PR #1033) that I wanted to toss out there.
Has there been a past effort/consideration to further categorize the settings? E.g. sorting/categorizing settings like:
This sort of setup might be clearer to newer users. This is opposed to the current approach where everything is listed out in alphabetical order and all mixed together where either you need to know the context of/be familiar with the setting or go look it up either in the ARMI docs or grep the App source code.
Anyway, just a thought. There are likely loads of complications that prevent this sort of thing. But I figured I'd bring it up as we try and get more and more users for ARMI apps.
Beta Was this translation helpful? Give feedback.
All reactions