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
As found by @jordancaraballo, if you fork, say, GEOSgcm, mepo will fail because all the relative links are "wrong". The relative links will point to the fork and not the canonical repo.
This is mainly for @tclune and I to ponder over. Maybe there should be a "canonical" repo in the yaml file that mepo can compare against? And if the fixture (origin) remote doesn't match it, then you say all sub-repos are a
The text was updated successfully, but these errors were encountered:
I think this concern was raised at least once before. Presumably forks of lower layers are more likely than of the fixtures. OTOH, if someone is not a collaborator and wants to save their config on a branch, they would need to fork the fixture too.
A purist might argue we should simply not take advantage of the relative repos and have explicit URL's for everything.
At one point I advocated that there should be something like a HOST_URL entry in the YAML file and then the individual entries for the repos would have something like ${HOST_URL} which would be interpolated by python before sending on to git. Thin, if a user does not change this, the repos will all come from the original org unless otherwise specified. Could even generalize it with an aliases section:
URL_ALIASES:
- GEOS-ESM: ...
I think this is similar to your "canonical" repo, but maybe slightly different implications.
As found by @jordancaraballo, if you fork, say, GEOSgcm, mepo will fail because all the relative links are "wrong". The relative links will point to the fork and not the canonical repo.
This is mainly for @tclune and I to ponder over. Maybe there should be a "canonical" repo in the yaml file that mepo can compare against? And if the fixture (origin) remote doesn't match it, then you say all sub-repos are a
The text was updated successfully, but these errors were encountered: