Match asset names with regex before os/arch/other filterings occur

[yjoer]

I am from #75 and #99, and found out that there's no traction yet, so I started it. I placed a regex-based matcher after validating for recognized archive formats and before OS/arch/other filterings occur. If the regex patterns yield multiple matches, the assets are propagated to the existing filtering mechanisms. Otherwise, if there's only one match, it is selected directly for downloading.

It might sound confusing, but the difference from the existing matching string is that the former is intended for disambiguation, while the new addition is used for shortlisting or arbitrarily selecting the exact release.

The limitation is that the regex crate does not support negative lookahead (rust-lang/regex#127) to exclude names matching negative patterns. Nevertheless, this remains helpful to exclude unwanted packages like *-debug-info.tar.gz on https://github.com/shader-slang/slang. The same is for #99 (comment). The following command demonstrates excluding packages with debug-info, while relying on os/arch filters to select the final package.

ubi -p https://github.com/shader-slang/slang --matching-regex "\d+\.tar" --extract-all

For #75, the wanted archive can be selected with \w+-\d\.\d\.\d\.zip.

[autarch]

Hi, thanks for your PR! I'm pretty finicky about my projects (see this blog post for details), so I rarely merge a PR as-is. I can move forward on your PR in one of two ways:

1. I check it out locally, fiddle with it as needed, merge it locally, and simply close this PR. This will preserve at least one commit with your name on it, but the PR will show up as closed in your GitHub stats.
2. If you enable me to push directly to your PR branch (which is the default when you make a PR), I can do my fiddling, then force push to your PR branch and merge the resulting PR. Again, this will preserve at least one commit with your name on it, but you also get credit for the PR merge in your GitHub stats. The only downside is that I will be force pushing directly to your PR branch. Note that this will not work if the PR branch is named master. GitHub doesn't allow me to push to the default branch of your fork.

Please let me know which approach you'd prefer. If I don't hear from you before I get around to working on this PR I'll go with option 1.

Thanks again for your contribution!

[autarch]

This looks good overall. I think this also needs a test for the case where the regex doesn't match, to make sure it returns the expected error.

Also, it'd be good to add an integration test in ubi-cli/tests/ubi.rs.

Thanks again!

[yjoer]

Thanks for your thorough review! I applied the suggested changes in a new commit and am adding a test case for situations where a pattern yields no matches. Please don't hesitate to make any changes to my branch.

[yjoer]

I have also added an integration test. All tests are passing on my machine. Let me know if any other changes are needed.

[autarch]

I think this is nearly ready to merge, so ...

---

Hi, thanks for your PR! I'm pretty finicky about my projects (see this blog post for details), so I rarely merge a PR as-is. I can move forward on your PR in one of two ways:

1. I check it out locally, fiddle with it as needed, merge it locally, and simply close this PR. This will preserve at least one commit with your name on it, but the PR will show up as closed in your GitHub stats.
2. If you enable me to push directly to your PR branch (which is the default when you make a PR), I can do my fiddling, then force push to your PR branch and merge the resulting PR. Again, this will preserve at least one commit with your name on it, but you also get credit for the PR merge in your GitHub stats. The only downside is that I will be force pushing directly to your PR branch. Note that this will not work if the PR branch is named master. GitHub doesn't allow me to push to the default branch of your fork.

Please let me know which approach you'd prefer. If I don't hear from you before I get around to working on this PR I'll go with option 1.

Thanks again for your contribution!

[yjoer]

Please don't hesitate to make any changes to my branch.

I prefer to go with 2.

[autarch]

Doh, sorry, I forgot I'd already asked.

[autarch]

Merged, thanks!