Skip to content
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

more systematic import of packages #670

Closed
Tracked by #358
LenkaNovak opened this issue Mar 5, 2024 · 0 comments · Fixed by #729
Closed
Tracked by #358

more systematic import of packages #670

LenkaNovak opened this issue Mar 5, 2024 · 0 comments · Fixed by #729
Assignees
Labels
🍃 leaf Issue coupled to a PR 💰 Grab Bag

Comments

@LenkaNovak
Copy link
Collaborator

LenkaNovak commented Mar 5, 2024

It would be good to decide on our convention on how we import packages and the short hands for them. (e.g. CA for ClimaAtmos).

solution

  • if using a Clima package that we commonly use, use import PackageName as PN (e.g. ClimaAtmos -> CA, SurfaceFluxes -> SF)
  • if using an external package, use import PackageName (e.g. for Dates or JLD2)
  • if using a module within ClimaCoupler, use import ClimaCoupler.Module: struct1, function1, function2, ...
  • maintain flexibility within this approach, especially to prevent the need to qualify e.g. macros or symbols we use from other packages

package shorthands:

  • ClimaAtmos -> CA
  • ClimaCore -> CC
  • ClimaCoreTempestRemap -> CCTR
  • ClimaLand -> CL
  • SurfaceFluxes -> SF
  • Thermodynamics -> TD
  • ClimaAnalysis -> CAN
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍃 leaf Issue coupled to a PR 💰 Grab Bag
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants