Allow installing a package from outside a manifest

[emberian]

Consider /~https://github.com/cmr/hgl-rs/blob/master/.travis.yml. It installs glfw-rs manually just so it can be available when building the examples, but otherwise nothing depends on them.

[wycats]

Can you say what workflow you would like for this?

[emberian]

cargo install http://github.com/bjz/glfw-rs.git, ideally.

[emberian]

And then I can use cargo rustc to pick that up to link to it.

[untitaker]

That'd be #1318

[icorderi]

Hey guys, I was pointed in this direction by Alex.
It seems [RFC]/PR (#1318) has been closed by the guy who proposed it due to lack of time.

There are a bunch of good ideas scattered around:

• cargo package (Need a way to bundle up the crate components into a deb, rpm, tar, zip, or installer #557 and later on [RFC] Naive local cargo-install #1318): package already exists but not as described in those threads.
• cargo install foobar ([RFC] Naive local cargo-install #1318, New commands for { install, upgrade, uninstall, list } packages directly from crates.io #1593)

Needed for a comprehensive feature set (#1593):

• cargo uninstall foobar # or remove...
• cargo view foobar
• cargo list
• cargo upgrade foobar

Here is my attempt to an RFC.

Btw, @alexcrichton can we use rust-lang/rfcs for Cargo related rfcs (add a cargo/ folder)? if not, can we have an rfcs/ folder on cargo itself where we can place the .md of ongoing RFCs and collaborate?

[RFC] - Extended package management

version: 0.0.1

[back-end] local repository

To make this possible we need some sort of local repository running on the machine.
System wide and local to the user need to be considered.

[command] cargo package

Scope: This command only works from inside a cargo project.

Possible packaging outputs include but are not limited to: deb, rpm, tar, zip, or installer (Windows).

This feature does not interact with the local repository.

Other considerations

We need to consider architectures.

cargo package [github-url] might be a possibility too, but not clear on the use cases of creating a new package without needing to have the code.

[command] cargo install [crate.io[version] | github-url]

Scope: Works inside or outside a cargo project.

When run from outside a cargo project the crate name or github-url is required. It will download the package or source, compile and install on the machine.

When run inside a cargo project (and no crate arguments), it will compile and install that project in the machine.

Other considerations

Do we want the outputs of cargo package to interact with the repository when unpackaged on the target machines?

Examples

> cargo install foobar
foobar 0.1.2 installed (crates.io)
> foobar
Hello foobarians!
> cargo install /~https://github.com/example/repo-rs.git
repo 0.0.1 installed (/~https://github.com/example/repo-rs)

[command] cargo view crate.io

Scope: This command only works from inside a cargo project.
Displays information on a package (installed or not).
Possible information displayed would be:

• installed version is available,
• the latest version on crates.io.
• dependencies (are they installed? which version is on the system, whats available on crates.io)

Examples

> cargo view foobar
foobar 0.1.2 (0.3.7 is available)
    | foo 0.0.3 (0.2.0 is available)
    | bar 0.1.2 (0.1.8 is available) 
> cargo view oops
oops not installed (0.1.0 is available)
> cargo view qwerty
qwerty crate does not exist

[command] cargo list

Scope: This command is valid anywhere.

The purpose is to know what packages are available on the computer.

Other considerations

We need to consider system wide + user local.
Can the repository know what source code only projects are available but not installed? (might be overcomplicating things)

Examples

> cargo list
foobar 0.1.2 installed (0.3.7 is available)
repo 0.0.1 installed (/~https://github.com/example/repo-rs.git [behind 9 commits])
> cargo list --dependencies
foobar 0.1.2 installed (0.3.7 is available)
repo 0.0.1 installed (/~https://github.com/example/repo-rs.git [behind 9 commits])
The following crates are available as dependencies
foo 0.0.3 (0.2.0 is available)
bar 0.1.2 (0.1.8 is available) 

[command] cargo upgrade crate

Scope: This command is valid anywhere.

The purpose is to upgrade a package to a newer version.

Other considerations

If the current version is a hard dependency for some other crate then we need to keep that copy around too.
We also need to figure out how to swap between different versions of the same crate if we allow to have multiple versions installed (or just 1 installed + n versions as dependencies).

It is possible to use cargo update and have it be context dependent instead of adding a new command name. In this case, running it inside a cargo project or outside behave differently.

Examples

> cargo upgrade foobar
foobar 0.3.7 upgraded 

[command] cargo remove crate

Scope: This command is valid anywhere.

The purpose is to remove an installed package.

Other considerations

Similar to upgrade, we need to be careful when this crate is a dependency to another crate. We also need to consider removing all the dependencies that are not primary installs unless they happen to be dependencies to some other installed crate.

[alexcrichton]

@icorderi wow, thanks for writing this up! For now major changes/additions to Cargo are going through the normal Rust RFC process, so I would recommend drafting up an RFC for that repo to gain comments on this.

This is looking pretty good! Some hesitations that I've had in the past are:

• What's the scope of cargo install? Is it intended to install libraries? Only binaries? In terms of package management, isn't the "correct way" to install software through the distro's package manager, and is cargo install an antipattern as a result?
• How will cargo generate all these various kinds of packages? What kinds of native tools will Cargo depend on to build an RPM or a Windows installer? Are these sorts of tasks better suited to Cargo subcommands instead of Cargo itself?
• With cargo install, where are all the artifacts stored? Do we just have ~/.cargo/bin and such?
• How does cargo install interact with native dependencies? If a native dependency is a dylib, then it'll need to be installed on the local system as well. Some packages may also need things like native assets. This kind of configuration typically necessitates an "install script" in addition to a build script.

Some of these questions I don't have great answers to, but they may want to be at least considered before pushing too hard on this.

[alexcrichton]

Implemented as cargo install!