For the use case when the installation happens from an alternative crates registry (e.g. a registry like Cloudsmith) cargo install provides a --registry and --index parameters.

It should be simple to provide a way to pass a registry and index input parameters for the action. It's important that the values of these parameters is then used in the cache key.

These parameters are mutually exclusive. The --registry is just a named index. I.e. the user has to have the following in the config.

[registries.registry-name]
index = "URL"

I am not sure how hard it will be to support version wildcards with alternative registries. I suppose listing the registry isn't included in the registry web API requirements. It would be at least something if only exact versions are supported for alternative registries

At servo we are using same workflow on ubuntu 22.04 for PR builds and 20.04 on nightly builds. Because the cache has version from 22.04 cached version does not work on 20.04 (due to different version of GLIBC). Hash must not only depend on runner os, but also on version of OS (at least on linux).

See servo/servo#30835

My GitHub workflow file looks like this:

      - name: Install typst
        uses: baptiste0928/cargo-install@v3
        with:
          git: https://github.com/typst/typst
          tag: v0.10.0
          crate: typst-cli

First run

The first run of this workflow went perfectly:

Installing typst-cli...
  Fetching git commits for https://github.com/typst/typst...
  Resolved tag v0.10.0 to commit 70ca0d257bb4ba927f63260e20443f244e0bb58c
  Installation settings:
     repository: https://github.com/typst/typst
     commit: 70ca0d257bb4ba927f63260e20443f244e0bb58c
     path: /home/runner/.cargo-install/typst-cli
     key: cargo-install-typst-cli-70ca0d2-7d85079d63d8ab080a5b
No cached version found, installing typst-cli using cargo...
Added /home/runner/.cargo-install/typst-cli/bin to PATH.

Subsequent runs

However, all subsequent runs fail with this error:

Run baptiste0928/cargo-install@v3
  with:
    git: https://github.com/typst/typst
    tag: v0.10.0
    crate: typst-cli
    locked: true
    version: latest
Installing typst-cli...
  Fetching git commits for https://github.com/typst/typst...
  Error: Failed to resolve tag v0.10.0 for https://github.com/typst/typst

The upstream repository did not delete the tag in the mean time, it's still there: https://github.com/typst/typst/tree/v0.10.0

I imagine this is a problem with how caching is handled?

See umccr/reusable-github-actions@8f8f053 for more context.

- name: Install several audit crates
  uses: baptiste0928/cargo-install@v1
  with:
    crate: 
       - cargo-deny
       - cargo-udeps
       - cargo-outdated
       - cargo-pants
       - cargo-audit

In my project, I'm seeing deprecation warnings about Node12. They look like:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: baptiste0928/cargo-install@v1

I see that your action.yml file does specify Node16 - Can you give any hints about how to avoid the warning above? Many thanks.

Hi, I'd like to install Rust projects that are on github but not on crate.io.

To be specific, projects like iden3/circom on github are not uploaded to crate.io. I can install them with cargo install --git <url> without caching, and it's possible to fetch the github API to check the repo's latest tag/release for caching.

I plan to work on a new major release (with breaking changes) soon.

• Use exact crate version if full version specified. See #7.
• Support installing multiple crates at once. See #4.
• Set locked to true by default to prevent sudden CI failures.
• Update to Node.js v16.

Hi again --

Noticed that the latest version of a crate is being installed even though a fixed version is specified.

For example, this workflow installed version 0.22.2: https://github.com/nextest-rs/nextest/actions/runs/3389729301/jobs/5633134431

With this workflow file: https://github.com/nextest-rs/nextest/actions/runs/3389729301/workflow#L104-L107

Could you look into this? Thanks!

Hi again :)

For cargo-nextest, I'd like to recommend folks install it with --no-default-features in CI. The default set of features includes self-update functionality that isn't relevant in CI. Would it be possible to add that? Maybe as a default-features: false parameter, similar to Cargo.toml.

I'd like to see the cached crate when looking at the caches for the repo, right now for example I see like 10 entries with cargo-install-{hash}

Using this action I did get the following warning:

Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I'm the original author or cargo-search2. Thank you so much for writing this! This is so much better and I'm going to start pointing users over to this.

Comparing this to cargo-search2, it seems like the only thing this is missing is a way to bump the cache key and invalidate the cache. Would you be willing to add it? I think it should be pretty easy to do so.

Thanks again!

Hi there!

When installing a package using this action, I've been getting these warnings:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Based on a quick look a simple lockfile update should fix this. Could you do so and publish an update? Thanks!

Comment on Reddit by a crate.io team member about another project querying the crates.io API:

Looking at the change you made in the fork (and using serde as a quick example), I think it would be fairly trivial to convert from parsing https://crates.io/api/v1/crates/serde/versions to https://index.crates.io/se/rd/serde instead — the same general metadata is available in both; you'd just have to newline split the sparse index version before parsing, and then convert a few field names. I don't think you'd need to pull in any additional dependencies.

That would definitely help us out: API requests have to go through the full crates.io webapp and to the database, whereas the sparse index is essentially just a static file from S3 via a CDN. Should be both speedier for you and cheaper for us.

Thanks!

I recently saw this warning pop up in my CI logs:

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: baptiste0928/cargo-install@v2. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

At the time of this writing, #15 (comment) was implemented without the support for version wildcards. Users must pin a specific package version to use this action with an alternative cargo registry.

This issue was created based on the comment #15 (comment) which suggests downloading the git registry index to figure out the available versions of the package and match the version selector against that index.

The outcome of this issue is that it should be possible to use a semver wildcard in the version input of the action together with any registry and index parameters for non-crates-io registries.

Thank you for the action, I'm using it in swc proejct (https://swc.rs)

Recently [email protected] is published and CI fails with

  error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
     --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-epoch-0.9.8/src/atomic.rs:314:6
      |
  314 | impl<T: ?Sized + Pointable> Atomic<T> {
      |      ^
  ...
  346 |     pub const fn null() -> Atomic<T> {
      |     -------------------------------- function declared as const here
      |
      = note: see issue #93706 <https://github.com/rust-lang/rust/issues/93706> for more information
      = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable

so I think the solution is to add --locked to cargo install.