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

mepo fails with forks #103

Open
mathomp4 opened this issue Sep 3, 2020 · 1 comment
Open

mepo fails with forks #103

mathomp4 opened this issue Sep 3, 2020 · 1 comment
Assignees
Labels
bug Something isn't working question Further information is requested

Comments

@mathomp4
Copy link
Member

mathomp4 commented Sep 3, 2020

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

@mathomp4 mathomp4 added bug Something isn't working question Further information is requested labels Sep 3, 2020
@tclune
Copy link
Contributor

tclune commented Sep 3, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants