No regex capture while parsing search output for ...

[pauldance]

No regex capture while parsing search output for ...

[PaulDance]

Hi @jwest23,

Thanks for the detailed report!

I can indeed easily reproduce the issue. Using -vvv, we can see that:

TRACE cargo_liner::cargo > Search for "tokei" got: "tokei = \"13.0.0-alpha.0\"    # Count your code, quickly.\n... and 38 crates more (use --limit N to see more)\n"

The search in itself therefore succeeds, but the version extraction then fails. Looking at the cargo::finish_search_exact function, we can see that [0-9.abrc]+ is used as the regular expression capture group in order to match and extract the version string: it is too conservative and does not match any - or alpha.

This should therefore be easy to fix: extending the capture group to be something in the likes of [0-9a-zA-Z.+-]+ should do the trick. Indeed:

• Cargo and crates.io use SemVer, or some close variant of it.
• The SemVer specification shows only these characters are used.
• semver::Version::parse will still do the proper strict parsing on top of the lax extraction.

I'll try this some time soon, most probably tomorrow night at the latest.

Thanks for cargo-liner and for looking into this!

❤️

[PaulDance]

Yes, I see what you mean. Thanks for clarifying.

However, you should know that the versions passed onto calls to cargo install are exactly the values of the packages config section without any kind of transformation whatsoever and it handles it just fine: that was by design. You can see that if you run:

❯ cargo install --version '*' cargo-nextest
    Updating crates.io index
  Installing cargo-nextest v0.9.61

What you want should therefore already be done: only the stable version is used. The versions that you see on the standard output are only coming from the result of calls to cargo search and is only used for display and in order to detect whether a new version is available or not.

It therefore seems to me the two issues are separate: could you move that into another issue then? Also please keep bugs and feature requests separate as well, it helps my understanding of things.

[PaulDance]

@jwest23 The issue I just opened should cover what I found concerning this from the point of bugs. Feel free to open another bug or feature request issue if it does not cover exactly what you had in mind, however.

[PaulDance]

The commit I just pushed should fix the direct issue:

• cargo-nextest v0.9.61
• tokei v12.1.2

were installed instead of the pre-release versions available. You should thus be able to use that commit by installing from source with cargo install --git [...] while waiting for a proper release.

I am therefore going to close this, but if it actually does not work for you, feel free to re-open it.

[PaulDance]

Yes, with your recent #9 and #8 being postponed, I'm planning on doing that in the coming days, especially if you're expecting it.

[jwest23]

My "Expected Behavior" could use a little polish.

Expected Behavior
Installation of cargo-nextest 0.9.59 and tokei 12.1.2, with an alert that these newer versions are also available.

When encountering a version with a pre-alpha or build metadata extension such as cargo-nextest 0.9.62-a.2 or tokei 13.0.0-alpha.0 cargo-liner would:

1. alert me that these versions are available
2. walk backwards through the versions until it finds a version without an extension and if it finds one, consider that the latest version instead
3. never automatically upgrade to a version with a pre-alpha or build metadata extension; maybe allow it with a command-line switch or other configuration

This is similar to the behavior of cargo-update; cargo install-update --list shows both of these as:

Package                 Installed  Latest                                                    Needs update
cargo-nextest       v0.9.61     v0.9.61 (v0.9.62-a.2 available)          No
tokei                       v12.1.2     v12.1.2 (v13.0.0-alpha.0 available)  No

which is helpful when deciding how I want to proceed.

Thank you again! cargo-liner has greatly improved the consistency of which tools are available to me in my various environments and saves me a ton of time!

[Johnabell]

Would it be possible to make this fix available in a release version now? We also ran into this issue in our CI pipeline.

[PaulDance]

Fix released as part of v0.4.2.