-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming conventions for files in cime_config/ #4076
Comments
@mnlevy1981 thanks for taking this on - I'm interested in seeing what a prototype of each of the options would look like. Maybe start with option 3 (or another if others feel strongly about it). |
I would also lean slightly towards (3) (then (2) then (1)). But in thinking about this a little more, I'd prefer if the package name were more specific than So maybe option (3) but a path like |
Other suggestions from telecon: NOT ${COMPNAME}_py because another model may use that in some other context. We all liked option 3 and just need to settle on a name. |
I think that the ideas proposed here will also make for a cleaner method of importing system test modules that are defined in components. For example, see this comment that I wrote a while ago: |
Background
In recent CSEG meetings, we talked about file naming conventions to maintain consistency among all the components -- namely, should python files have the
.py
extension or not. The prevailing view was that python modules that are meant to be imported should have the extension, scripts that should be run from the command line should not have it, and files that currently do double duty viaif __name__ == "__main__"
blocks should be split into two files (a.py
module and a extension-free wrapper).One big hitch to this plan is how CIME treats
cime_config/buildnml
. Currently there is logic that tries to import specific functions frombuildnml
, and falls back to executing the script viasubprocess
. @billsacks and I chatted about how to modify CIME to follow these conventions, and came up with some interesting ideas we thought were worth discussing.Potential paths forward
Assuming other groups agree that this would be a nice convention to follow, there a few possible ways to proceed.
run_sub_or_cmd()
to try to importf"{filename}.py"
before falling back on the current behavior of trying to importfilename
and runningfilename
if the import fails. Perhaps in a later version this could collapse to "try to importfilename.py
or runfilename
", but leaving the middle check would maintain backwards compatibility for the current version.cime_config
a package (i.e. include__init__.py
). Then we could try to importcime_config
, and fall back to the current behavior in CIME6 (again, perhaps cutting out theimport filename
option in future versions). This could potentially clean up some python code in components -- one example is that POP has a python layer that sits betweenbuildnml
; if these functions are included in thecime_config
package it is easier to import them intobuildnml
.cime_config/${COMPNAME}/__init__.py
; this would let us more cleanly separate the python code incime_config
from the XML and the test suite files. It might also let us clean upimport
statements since there is no longer a namespace conflict every time you import a newbuildnml
(orcime_config
in the above option)Questions
buildnml
a wrapper script that importsbuildnml.py
?In case it changes how you answer the above questions, I'll note that I am happy to take lead on implementing whatever solution results from this issue ticket.
The text was updated successfully, but these errors were encountered: