Support running an external program to "score" alternate files

[erijo]

Is your feature request related to a problem? Please describe.

This is a RFC to see if this is a good idea or not.

A number of issues (e.g. #185, #202 and #213) request adding support for different types of conditions. Instead of adding support for these and future ones, how about making it possible to run an external program to score files?

Describe the solution you'd like

The idea is that you can add conditions on the form: p.<a string that doesn't contain a comma>. p is an alias for parameter, but a better name would be good. Upon seeing this condition, score_file would then call $YADM_DIR/eval_alt_condition (or something) with the value after p. as the single parameter. $GIT_DIR (and possible other variables) are set in the environment to enable the script to look up values in the repo. The script should then exit with 0 if this condition is true and with something != 0 otherwise.

If you have multiple p's, the script would be called multiple times and all would have to return true (0) for the alternate to be considered.

Describe alternatives you've considered

None.

Additional context

N/A

[TheLocehiliosan]

I do like the approach of empowering others to make alternates work the way they need.

Depending on how many alternates were using this type of condition, I could see performance being problematic. Perhaps the interface could have a single call to the "scoring program", and provide a full list of alternates that need scoring. Of course, I also don't really love the idea of parsing a bunch of output, and negotiating a "protocol".

I agree that naming is a tricky thing to get right. I'll think on some suggestions.

It would probably help if we had some example use cases with some proposed alternate file names. Might help shake out other caveats and ideas.

I do think this is a good idea, likely just need to expand the plan a bit....

[erijo]

Some use-cases, using x (for "external") instead of p:

• For Support a host having multiple local classes? #185: x.class=build,x.class=gui,x.not_class=server
• For Include architecture in alternate selection #202: x.arch=arm
• For Use ID_LIKE from /etc/os-release to specify alternatives based on distro family #213: x.like=debian

I did a test implementation to be able to experiment with this. Will post it as a PR shortly.

[xenoterracide]

@erijo I'm not certain what you're cooking up, but maybe plugins would be the right way to go, otherwise all of these things are just going to be re-implemented over and over.

[erijo]

I was trying to come up with a way so that yadm wouldn't have to support all possible ways that people would like to differentiate files on. It gives a lot of flexibility to the end-user.

One of the down-sides is, as you write @xenoterracide, that some features risk being implemented over and over again. This could be avoided somewhat by having scripts in the contrib directory.

One other down-side is that once this feature exists, no one (?) will file issues when something is missing in the alternate system so yadm will not gain features that may be useful to more than a handful of people.

There's also the question of performance that was raised by @TheLocehiliosan.

So, I'm not sure this is the solution to all these issues, but I think it's something to consider.

[TheLocehiliosan]

I am interested in a flexible system like this that can empower users to devise their own support for alternate files in many different original ways. However, I do not see a such a feature as the only way new classifications can be handled going forward. I'm also interested in expanding the built-in supported classification options for alternates, especially for the cases that will impact the most users.

I think both expanding the supported classifications AND exposing a way to customize the classification system are good goals for yadm.

[github-actions]

This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.