Automatic management of the components.yaml

[tclune]

With mepo's current implementation, various commands that impact the state of a fixture or subprojects are not automatically reflected in the components.yaml file that was used to create the initial configuration. Generally this means that this file must be hand edited when updates are pushed back to the repository.

This situation has worked well for some use cases, but it less ideal for more intermediate work involving peer-to-peer exchanges of status. In particular, it leads to the desire to push "deep" tags across the entire hierarchy of repositories which is a form of namespace pollution. But it is also arguably just adding (to whatever degree) to the complexity of managing the repositories.

@amdasilva has suggested instead that the top configuration information should be automatically updated as mepo commands alter the state. E.g., if mepo is used to checkout branch foo in subproject bar then the configuration file should change the entry tag: xyz in the bar clause to branch: foo.

One immediate issue that must be considered with this change is what we mean by mepo status. Currently this shows any changes since the original clone step (or the most recent mepo save). Presumably with the proposed change the behavior is as-if a mepo save is issued after each step, and a different mechanism must be used to compare against an earlier point in development. (Possibly a capability like this already exists in mepo?)

I'll attach a few more related concerns in subsequent comments in this GitHub issue.

Bringing to attention of @mathomp4 @amdasilva @sdrabenh and @rtodling

[tclune]

If we implement this change we should also relocate the configuration yaml file to something like .mepo/mepo-config.yaml. This suggestion is from @amdasilva, and derives from the fact that humans should no longer be editing this file once it is automatically maintained.

[tclune]

For intermediate development we will start to see a lot more SHA codes in the config file (which people should not be looking at anyway), but probably worth noting.

Something to keep in mind with this though is that "orphaned" SHA codes can be (and will be) pruned on GitHub after some period of time. If a configuration needs to be maintained and there is any concern that the underlying subproject states will not ultimately be merged into a permanent branch (eg main or develop), then tagging subprojects is still necessary unfortunately.

[tclune]

Another concern is for users that take some action via git rather than mepo. mepo save can capture the state, but ... Suppose I use git to checkout a specific tag of MAPL inside the GCM fixture. Can mepo "know" whether to capture the SHA code vs the tag? A given SHA may have multiple tags (though this is unlikely in the case of MAPL.)

[tclune]

To be useful, mepo will also need a push that ensures all branches in subprojects have been pushed to GitHub. This might be a bit difficult for a headless commit. Possibly this situation is rare enough that mepo would just issue an error saying that it cannot handle headless commits?