Does binstall work for private crates?

[metasim]

Can binstall be used for crates that are not published to crates.io, in a non-public GitHub repo?

[NobodyXu]

That's possible, the simplest solution is to write a "Cargo.toml" which includes crate name, version and link to repository, and then provide a GITHUB_TOKEN which has at least read access to the private repository.

If you want something more elegant, then you can create a private cargo registry and use them in cargo-binstall.

[scullionw]

we are currently facing an issue, and not sure if we are doing something wrong

GITHUB_TOKEN=ghp_XXXXXXXXX cargo binstall --strategies crate-meta-data --git https://github.com/TransitApp/gtfsRtProcessor.git gtfsrt-analyzer

 INFO resolve: Resolving package: 'gtfsrt-analyzer'
Username for https://github.com: scullionw
Password for https://scullionw@github.com:
 INFO Cloning with worktree::receiving pack: Enumerating objects → 684.0 objects
 INFO Cloning with worktree::receiving pack: Compressing objects → 14.0/464.0 objects [3%]
 INFO Cloning with worktree::receiving pack::read pack → 1.3MB
 INFO Cloning with worktree::receiving pack::read pack → 6.3MB
 INFO ℹCloning with worktree::receiving pack::create index file::indexing → done 684.0 objects in 1.23s (558.0 objects/s)
 INFO ℹCloning with worktree::receiving pack::create index file::decompressing → done 19.9MB in 1.23s (16.3MB/s)
 INFO ℹCloning with worktree::receiving pack::create index file::Resolving → done 684.0 objects in 0.11s (6.4K objects/s)
 INFO ℹCloning with worktree::receiving pack::create index file::Decoding → done 21.9MB in 0.11s (204.5MB/s)
 INFO Cloning with worktree::receiving pack::create index file → 3 of 4 steps
 INFO ✓Cloning with worktree::receiving pack::create index file::writing index file → done 20.2KB in 0.00s (112.3MB/s)
 INFO ✓Cloning with worktree::receiving pack::create index file → done 684.0 objects in 1.33s (513.0 objects/s)
 INFO ℹCloning with worktree::receiving pack::read pack → done 14.1MB in 1.63s (8.7MB/s)
 INFO ℹCloning with worktree::receiving pack::checkout → done 217.0 files in 0.03s (7.7K files/s)
 INFO ℹCloning with worktree::receiving pack::writing → done 20.8MB in 0.03s (736.9MB/s)
 INFO HEAD on https://github.com/TransitApp/gtfsRtProcessor is not allowed, fallback to GET
 INFO HEAD on https://github.com/TransitApp/gtfsRtProcessor is not allowed, fallback to GET
 INFO HEAD on https://github.com/TransitApp/gtfsRtProcessor is not allowed, fallback to GET
 WARN resolve: Error while checking fetcher invalid url: Failed to download from remote: could not GET https://github.com/TransitApp/gtfsRtProcessor: HTTP status client error (404 Not Found) for url (https://github.com/TransitApp/gtfsRtProcessor)
 WARN resolve: Error while checking fetcher invalid url: Failed to download from remote: could not GET https://github.com/TransitApp/gtfsRtProcessor: HTTP status client error (404 Not Found) for url (https://github.com/TransitApp/gtfsRtProcessor)
 INFO HEAD on https://github.com/TransitApp/gtfsRtProcessor is not allowed, fallback to GET
 WARN resolve: Error while checking fetcher invalid url: Failed to download from remote: could not GET https://github.com/TransitApp/gtfsRtProcessor: HTTP status client error (404 Not Found) for url (https://github.com/TransitApp/gtfsRtProcessor)
 WARN resolve: Error while checking fetcher invalid url: Failed to download from remote: could not GET https://github.com/TransitApp/gtfsRtProcessor: HTTP status client error (404 Not Found) for url (https://github.com/TransitApp/gtfsRtProcessor)
ERROR Fatal error:
  × For crate gtfsrt-analyzer: Fallback to cargo-install is disabled
  ╰─▶ Fallback to cargo-install is disabled

it is a private github repo, and the crate is not in any registry. the release artifact is stored in the github releases.

it seems the github token works for pulling the Cargo.toml from the github repo, but then fails for some other requests for the same url? The github token has all privileges

Is --git the correct mode to use?

[NobodyXu]

Yes, but it looks like cargo-binstall can't access the private repository.

We only use GITHUB_TOKEN to speedup the access, and we actually have a few requests created without the token.

It's a bug that will get fixed,