baptiste0928/cargo-install

Add support for `--registry` and `--index` parameters

Veetaha opened this issue · 6 comments

Veetaha commented

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

baptiste0928 commented

I'm not familiar with alternative registries, but implementing version resolution as currently done with crates.io will not be possible without an easy way to query all available versions.

This might be possible with sparse indexes, but not all registries support them, and even then it will require parsing the index configuration and registry configuration.

For now, the best option is - as you suggested - to support only exact version requirements. I'll try to find some time to implement this in the next few days.

If supporting version wildcards is a requirement for some use cases, you can always use a more generic caching action like the awesome swatinem/rust-cache action, but the cache will be invalidated more often and will not be invalidated when a new version matching the requirements is available.

baptiste0928 commented

Hey @Veetaha, I've implemented this in #18. Can you test if everything works for you before I merge it?

You can use the PR's branch like this:

-  uses: baptiste0928/cargo-install@feat/custom-registry
   with:
    crate: my-awesome-crate
    version: 1.0.0 # exact version, except if using sparse index
    # index or registry parameters

Let me know if it works or if run into any issue.

  • 👀1
Veetaha commented

Hey, I gave it a test run with the following setup (I redacted the names, since it uses a private registry):

uses: baptiste0928/cargo-install@b3ea78257dd2498a1656a5faa4aabbff8e287fd1
with:
  args: --bin bin-name
  crate: package-name
  index: https://dl.cloudsmith.io/basic/org-name/repo-name/cargo/index.git

This failed with the following output

Installing package-name...
  Error: Version ranges can only be used with sparse indexes

Unfortunately, we don't use a sparse index due to the lack of support for auth (rust-lang/cargo#10474). Then I tried specifying an exact version and it worked

uses: baptiste0928/cargo-install@b3ea78257dd2498a1656a5faa4aabbff8e287fd1
with:
  args: --bin bin-name
  crate: package-name
  index: https://dl.cloudsmith.io/basic/org-name/repo-name/cargo/index.git
  version: x.y.z
Installing package-name...
  Using non-sparse index, skipping version resolution
  Installation settings:
     version: x.y.z
     path: /home/runner/.cargo-install/package-name
     key: cargo-install-package-name-x.y.z-1f65051c7c713cc24cf4
No cached version found, installing package-name using cargo...
Added /home/runner/.cargo-install/package-name/bin to PATH.
Installed package-name x.y.z.

and caching works

  Cache Size: ~N MB (Nbytes B)
  /usr/bin/tar -xf /home/runner/work/_temp/a10cde7f-25fd-4081-bd19-9d18a9901d59/cache.tzst -P -C /home/runner/work/org/repo --use-compress-program unzstd
  Cache restored successfully
Restored package-name from cache.
Added /home/runner/.cargo-install/package-name/bin to PATH.
Installed package-name x.y.z.
Received Nbytes of Nbytes (100.0%), K.P MBs/sec

But would it be possible to support the use case at the top where the version is not specified? Meaning it should install just the latest version? I suppose there will be a problem of setting the cache key since no version is known at this point?

baptiste0928 commented

But would it be possible to support the use case at the top where the version is not specified? Meaning it should install just the latest version? I suppose there will be a problem of setting the cache key since no version is known at this point?

You're right, the cache key needs the exact version being installed so it can restore from the cache and skip cargo install entirely. Version resolution was previously done using the Crates.io API, I rewrote it to use the sparse index instead (#16), so it can support at least some alternative registries.

For registries that do not support the sparse index, it will need to clone the registry index locally to do version resolution. It can be implemented, but I don't have time to do it right now. I'm open to contributions if you (or anyone else reading this issue) would like to try to implement it.

Veetaha commented

I don't think I have bandwidth for this contribution now, and it's not critical for me right now. I created a separate issue #19 targeted for supporting version wildcards so that we can close this one and have support for pinned package version installations, which is already good

baptiste0928 commented

I published the new version with registry support (v2.2.0)

  • 🎉1