Allow passing a crate name to cargo fetch

[Keruspe]

It would be nice to be able to do somehting like cargo fetch foobar to fetch foobar's dependencies.

I'm the rust packager for the Exherbo distribution, which is source based. An install is divided into steps: fetch, unpack, configure, compile, test, install

Only the fetch phase is allowed to use the network.
For now I added a hack disabling the sandbox just for the CARGO_HOME=... cargo fetch command, but it would be great if we could simply move that to the fetch phase, when we don't have unpacked the tarball yet (and thus when we don't have access to Cargo.toml yet).

[alexcrichton]

Hm cargo fetch currently requires a Cargo.toml, are you thinking that this would work without a Cargo.toml? Unfortunately that wouldn't work for any crate that's not on crates.io :(

[Keruspe]

Well, I was thinking of mirroring the cargo install behaviour. If a crate
name is provided, get it from crates.io, otherwise use Cargo.toml
On Tue, 16 Aug 2016 at 22:49, Alex Crichton notifications@github.com
wrote:

Hm cargo fetch currently requires a Cargo.toml, are you thinking that
this would work without a Cargo.toml? Unfortunately that wouldn't work
for any crate that's not on crates.io :(

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2998 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANm3g9EisbPOtLc2_nmS1JzGmjMSYzLks5qgiHZgaJpZM4JlRK7
.

[alexcrichton]

Hm so while conceptually that makes sense I'm not sure it fits in with Cargo's model of dependency fetching. That is, it's never necessary to cargo fetch foo, and cargo fetch foo isn't sufficient to then try something else as well. As a results it's not clear what it'd actually be used for.

[Keruspe]

Yep, I totally agree with your point. Having that feature wouldn't target people using cargo directly, it would really be packager-oriented.
It's only there for network sandboxing compatibility to be able to fetch everything, and then do the unpack + build + install with network sandboxing enabled.

[alexcrichton]

Yes but even for packagers it's not useful? After cargo fetch foo you still can't do anything. The purpose of cargo fetch is that it's executed on a project to download all its dependencies.

[Keruspe]

Well, as cargo fetches deps into CARGO_HOME, when running cargo build, it checks if they're present, and fetches them if they're not.
Let's say I want to install cargo-watch version 3.1.0
cargo fetch cargo-watch --vers 3.1.0 would download all the deps into CARGO_HOME.
I can then safely download the tarball, unpack it and run cargo build without any network access. That's what I'd want to achieve here, as the sandbox doesn't allow network access after unpacking.

[alexcrichton]

I can then safely download the tarball

Unfortunately that's not actually true. Projects aren't intended to be installed from crates.io, the source needs to be acquired from elsewhere for these kinds of builds.

[Keruspe]

Where does the cargo tool fetch the sources from (not that this would change anything regarding my issue)?

Maybe doing what I want in "cargo fetch" isn't the right solution.

What would be a proper solution to split everything network-related from a crate installation into one command, then everything else in another?

Would something like "cargo download" be better ?

To summarize exactly what I'd like to achieve here:

# All the downloading needed for the crate and its deps is done here, everything is stored in CARGO_HOME
CARGO_HOME=/var/tmp/cargo-home cargo download foo --vers 1.0.0
# Since everything is available in CARGO_HOME, cargo install don't need network at all
CARGO_HOME=/var/tmp/cargo-home cargo install foo --vers 1.0.0

I'm not trying to do cargo's work by hand, the least I do that, the happier I am. I just really need to split the network-related stuff.

[alexcrichton]

Where does the cargo tool fetch the sources from

crates.io

What would be a proper solution to split everything network-related from a crate installation into one command, then everything else in another?

This is intended to be used against a Cargo.toml, not as cargo install, but the command you're looking for is cargo fetch.

[cardoe]

@Keruspe You probably want to look at what we've been doing for Yocto, Gentoo and Debian since you are searching for a solution to the same problem. I opened a similar ticket #2861. But you should really look at #2857 and #2811. There's probably some other issues to look at but you're effectively asking for the same thing.

[cardoe]

I don't follow Exherbo development but I know its derived from Gentoo with an updated PMS. I've implemented support for directory registries with an eclass and it should be possible for Exherbo to use that for the support you need. See gentoo/gentoo#2918.

[carols10cents]

I believe this has been solved by #2857, cargo local-registry, and cargo vendor, so I'm closing.