chshersh / tool-sync

🧰 Download pre-built binaries of all your favourite tools with a single command
https://crates.io/crates/tool-sync
Mozilla Public License 2.0
72 stars 17 forks source link

Support full automatic asset guess even when 'AssetName' is not provided #50

Open chshersh opened 2 years ago

chshersh commented 2 years ago

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.

chshersh commented 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?

MitchellBerend commented 2 years ago

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.