How to match a repo with mixed release zip names?

[rhysm94]

Hi there!

I'm looking at using ubi with mise to install some tooling in my iOS project.

I've figured out how to get it to install an older version of Sourcery which has a release with only one zip file – Sourcery-2.0.1.zip. More recent versions of Sourcery have also started to be built for platforms other than macOS, meaning newer releases offer the following options:

• sourcery-2.2.5-ubuntu-22.04.4-lts-jammy-x86_64.tar.xz
• sourcery-2.2.5.artifactbundle.zip
• sourcery-2.2.5.zip

I know that sourcery-2.2.5.zip is the macOS release, but I can't figure out how to force this to be selected. When I try to install using the following command:

./ubi -p https://github.com/krzysztofzablocki/Sourcery -e sourcery --debug

I get the error:

[ubi][ERROR] could not find a release for this OS (macos) from sourcery-2.2.5-ubuntu-22.04.4-lts-jammy-x86_64.tar.xz, sourcery-2.2.5.artifactbundle.zip, sourcery-2.2.5.zip

Is there a way to force ubi to download that sourcery-2.2.5.zip release bundle?

Thanks!

[autarch]

The way --matching works is just to filter out multiple options after the OS and arch filtering. It's not a way to just select an arbitrary file.

I don't think there's a good way for ubi to handle this case. Honestly, I think the Sourcery project should adopt a more consistent release file naming scheme.

[Ernest0-Production]

I also really don't understand why the OS match is hardcoded into the ubi logic without the ability to override it (and not supplement it) with the --matching flag.
This greatly limits supportability with many utilities that do not comply with the standards.

[autarch]

I also really don't understand why the OS match is hardcoded into the ubi logic without the ability to override it (and not supplement it) with the --matching flag. This greatly limits supportability with many utilities that do not comply with the standards.

This is just the way I wrote it. It's not that it has to be this way. But changing it now has the potential to break existing use cases.

What I'm thinking is it might make sense to add a new option, something like --matching-regex, that would A) take a regex instead of just a string. If there was only one match for the regex, then ubi could just skip the OS & arch matching entirely in that case.

[Ernest0-Production]

@autarch Yes, it's a good idea.

[Ernest0-Production]

@autarch Hi! I'm not in a hurry, I want to just ask if there are plans to add this option after all?