Build frontend: Easily switch to branch/commit for component models

[jjokella]

From the first few user experiences with the nice new TSMP2-frontend, it was found that it could be nice to include a simple way of switching the branch/commit of a component model or PDAF.

Oftentimes users do not work on the exact submodule commits, but rather they are developing one or more of the component models.

Would it be relatively easy to include something like --PDAF_HEAD that one could provide with a branch name or commit hash and then this version would be checked out instead of the default submodule version?

[kvrigor]

I have initially suggested this in the frontend PR, but what if we change the signature to something like this:

./build_tsmp2.sh --eCLM <optional-arg> --PDAF <optional-arg>

where <optional-arg> could be one of these things: (1) an empty string (i.e. default behavior of using git submodules), (2) a specific branch or commit, or (3) path to some repo. Distinguishing between these cases can still be easily done in a shell script, plus we keep the number of options low for simplicity.

[s-poll]

Thank you for the feedback! I think implementing a commit hash/branch could be done very straight forward by modifying a few lines in the dwn_compsrc function.

@kvrigor : In general I like the idea of minimizing the number of options. However, the mentioned option (2) + (3) do not exclude each other. Thus, it can have either one of the options or both options. That make the implementation not so straight forward (at least I do not see an easy way) and might get more complicated when it points out that we need more options.

[kvrigor]

However, the mentioned option (2) + (3) do not exclude each other. Thus, it can have either one of the options or both options. That make the implementation not so straight forward (at least I do not see an easy way)

Mixed option 2 + 3 is surely possible but I doubt that it appears in practice. When a user specifies a path (option 3), my expectation is the user wants finer control of the source repo and thus can manage the repo by themselves. This mindset is very different from a user who wishes to specify a commit/branch (option 2); user still prefers the convenience of build_tsmp2.sh without manually tinkering the repo themselves. In short, these two options are use-cases that naturally springs from I want to manage the model repo myself vs. let the build script do the work for me.

... might get more complicated when it points out that we need more options.

I think these 3 options already cover most of basic use cases; anything more complicated than that I'd suggest to use the cmake front-end instead.

[jjokella]

Thanks for the comments! As I said, from my experiences, this change would benefit users, but I do want to keep the workload minimal.

From my side, two thoughts in this direction

• I like the idea of using the existing flags like --eCLM or --PDAF
• I would be completely happy with just the options (1) submodule and (2) branch/commit for these commits. Also, we do have the flags like --eCLM_SRC to specify a path, right? IMO both of them are fine to keep. Also, they can then be nicely combined.

[kvrigor]

Here's a sample implementation which covers all 3 cases without introducing excess flags. This doesn't look complicated IMO...

if [[ -z "$optional_arg" ]]; then
  # Empty optional_arg
  echo "No optional arg supplied: using git submodule..."
else
  # Non-empty optional_arg
  if [[ -d "${$optional_arg}" ]]; then
    model_src=${optional_arg}
    echo "Compiling ${model} from ${model_src} ..."
  else
    # simply assume a git commit hash or branch
    commit_id=${$optional_arg}
    cd ${model_submodule_path}
    if git checkout ${commit_id}; then
      echo "Success!"
    else
      echo "Invalid arg supplied to --${model}: ${optional_arg}"
      exit 1
    fi
  fi
fi

[jjokella]

Small update: It has become a habit for me to introduce commits in a submodule by changing the submodule-commit in a branch of TSMP2.

I think forcing developers to do introduce TSMP2-branches could be an alternative path - the downside is some extra git-commands, a larger number of branches in TSMP2 and corresponding branches needed in both the submodule and TSMP2 for testing.