Open chshersh opened 2 years ago
I propose the following design for better maintainability and understandability:
Model selection rules as an enum data type in a declarative way and specify rules for each OS.
To be more precise, model query as the following type:
enum Rule {
/// Asset name should contain a specified substring
Substring(String),
/// Asset name shouldn't contain a specified substring
Exclude(String),
/// Both rules should be satisfied
And(Box<Rule>, Box<Rule>),
/// At least one rule should be satisfied
Or(Box<Rule>, Box<Rule>),
}
Then, one can easily implement a recursive function for matching a string with a rule:
fn match(rule: Rule, s: &str) -> bool { ... }
A possible rule for macOS could look like this with some eDSL capabilities (after implementing BitAnd
and BitOr
traits):
Substring("apple-darwin") & (Substring(".zip") | Substring(".tar.gz")) & Exclude(".sha256") & Exclude(".md5")
Then, we just define such rules for each OS. And, ideally, users of tool-sync
should never need to specify asset names manually 🤞🏻
However, users still might want the ability to override the default rules for specific assets in case our rules don't cover their use case or some specific tool. So there's an open question: how much of this eDLS do we want to expose to users? Maybe we should just add another constructor like Exact
to just let users specify the asset name exactly, without any substrings or regular expression checks
cc @MitchellBerend @slyshykO What do you think?
I like this idea, not operations in regex are a real pain to do. I think the implementation of this feature depends on how much of the functionality we want exposed to the user. I think regex is common enough to assume users already know how to write correct patterns.
CLI tools on GitHub releases follow common naming schemes.
tool-sync
could guess asset names from releases without the need to specify part of the name.