GEOS-ESM / GEOSana_GridComp

Repository containing code for data analysis for the GEOS Earth System Model data assimilation
Apache License 2.0
1 stars 3 forks source link

Adding a new external component (components.yaml) #73

Closed jing-guo closed 2 years ago

jing-guo commented 2 years ago

I need to add a new external component @JCSDA_crtm/ into GEOSadas fixture, as a step to closely associate the old @NCEP_shared/NCEP_crtm/ to a living JCSDA component repository.

It was done easily before (pre-mepo time) through Externals.cfg through explicit parameters "remote=" and corresponding "local=<@JCSDA_crtm>". However, there is no explicit in the new mepo components.yaml file anymore, but a short notation of relative path, e.g. "remote: ../MOM6.git".

Any advice to proceed for a correct solution for this problem?

mathomp4 commented 2 years ago

@jing-guo You can put a full path in components.yaml. Right now you see things like:

MAPL:
  local: ./src/Shared/@MAPL
  remote: ../MAPL.git
  tag: v2.12.1
  develop: develop

That "short" notation is from Git Submodule notation where it means if you clone GEOSgcm with, say, the SSH URL, git@github.com:GEOS-ESM/GEOSgcm.git, then it uses the SSH URL as well and clones git@github.com:GEOS-ESM/GEOSgcm.git/../MAPL.git or git@github.com:GEOS-ESM/MAPL.git. Likewise, if you use an HTTPS URL, then mepo clones all the subrepos with HTTPS URLs.

This makes it easy to support places where SSH urls aren't useful (aka Amazon Web Services or Docker containers)

Now, we can use the relative URLs since we usually fork all our sub-repos into GEOS-ESM. But you can also add your own, so if you had:

MAPL:
  local: ./src/Shared/@MAPL
  remote: https://github.com/NOAA-EMC/JCSDA_CRTM.git
  tag: v2.12.1
  develop: develop

it would clone the NOAA-EMC repo for JCSDA_CRTM into the directory path of MAPL. I don't suggest doing this, but mepo will not stop you!

If you want to use a relative URL, then we could fork JCSDA_crtm into GEOS-ESM and then...there you go. It's in GEOS-ESM, so a relative URL will work.

jing-guo commented 2 years ago

Thanks for your great detailed explanation! To me, a fork of external JCSDA_crtm would certainly be a highly preferred solution. But that would be a higher level operation. If we want to do so, what is the process to get it done?

For the time being, because there are now a couple of different sources of CRTM repositories (including forks) we can choose from, I need to explore some of them to find out a proper one to take. So at lease for a while, I would need to use a full URL approach to get it moving. An entry for this would be something like this

JCSDA_crtm: local: ./src/Shared/@JCSDA_crtm remote: https://github.com/JCSDA/crtm.git tag: 84a3214 develop: ....

Is there any suggestion on specifying "develop:..." entry? Can I leave it blank until it become a fork of JCSDA/crtm.git?

mathomp4 commented 2 years ago

@jing-guo The develop: key is just what mepo looks at when you do mepo develop foo. So for now, maybe do:

develop: master

as they seem to have updated master a few days ago.

One last note: if you decide to checkout a repo under another repo, make sure you put its entry in components.yaml after the one it's in. For example, you need to have the GEOSchem_GridComp entry before GOCART since GOCART is under Chem.

jing-guo commented 2 years ago

Great! I will proceed following your advice. I believe eventually, we will need to fork a CRTM repo under GEOS-ESM from a chosen upstream source, and maybe other forks as well. But that will be a different issue.