Add customization for which artifact is selected

[Corecii]

Incentive

Most releases are formatted well for pulling in binaries with rokit, especially ones built for its ecosystem. Some tools from outside the ecosystem are well packaged for automatic downloads but have incompatible names or zip structures.

Proposed Solution

To support these without having to build a repackaging cron job, I suggest:

• Custom regex pattern for release name matching on each supported platform
• Custom glob or regex pattern for executable finding on each supported platform
• Custom name for the executable when placed on the system. Some tools, like cargo-make only work correctly if the executable is named correctly.

A fully-specified configuration could look something like this:

[tools.makers]
source = "sagiegurari/cargo-make@0.37.13"
bin_name = "makers"

[[tools.makers.targets]]
platforms = [ "windows_x64", "windows_x86" ]
release = ".*x86_64-pc-windows.*"
bin = "**/makers.exe"

[[tools.makers.targets]]
platforms = [ "linux_x64", "linux_x86" ]
release = ".*x86_64-unknown-linux.*"
bin = "**/makers"

In this example, the following fields are optional:

• release: if it's missing, we still use the target entry for finding the file, but we use the default release name matcher for the current platform.
• bin: if it's missing, we still use the target entry for finding the release, but we use the default file finder for the current platform.
• bin_name: if it's missing, we use the default bin name.

This is not a perfect example of why this is needed: cargo-make only needs the bin target customization to make sure rokit pulls makers.exe and not cargo-make.exe which both come in the same zip file. Still, it's a good example of the configuration format.

Tricky Details

For customizing the bin name, rokit already creates a unique folder for each version of a tool. Using a different name for the exe shouldn't cause any naming conflicts. If the user ends up with two copies of a tool because one manifest specifies the bin_name and the other does not, they can exist just fine in the same folder. The only waste is disk space, but if you're setting bin_name, it's probably because the tool only works if it's named properly, so you'll only have one properly named tool anyways.

For customizing everything else, it could create conflicts between manifests if two manifests ask for the same tool from the same repo with the same version but specify different artifact targets. I'm not sure what the best move there is, other than more specific folder names. For example, hashing the resulting artifact name + relative file path and putting it here .rokit\tool-storage\<user>\<repo>\<version>\<hash> would work for ensuring uniqueness.

Other Considerations

This is very close to being able to specify multiple files to be pulled in with a glob pattern. If we choose to do this, it may be worth leaving that route open, or just doing it from the very beginning. Some portable executables are lightweight and well-packaged, but they rely on some sibling libraries, especially on Windows. Not being able to pull these tools in with our toolchain manager because it can't just pull in a few extra files would be unfortunate!

I've deliberately chosen to (re)name the bin glob as bin to leave room for something like files, siblings, etc.

[filiptibell]

I think this is a great idea overall - it's mostly just figuring out the details, like you've noted down 😄 The main concern for me personally would be tool storage. Maybe we need a different structure entirely so that we don't need to make additional, potentially breaking changes to resolve issues like #5. I'd like to maybe add some kind of versioning and automatic migration mechanism to the tool storage for this.

Using globs from the start sounds good to me. It doesn't seem like much additional complexity over regex patterns and extracting single files, and I actually think during extraction of zips etc it would look very similar. If we figure out tool storage and ensuring each custom tool install has its own fully unique directory this should be fine. If users or tool maintainers are concerned about saving disk space, with each custom install having its own unique directory, it seems to me like an upstream issue with packaging and not something Rokit should worry too much about.