[RFC] Naive local cargo-install

[globin]

This adds a feature to install a compiled binary into a folder specified
by --prefix, by default ~/.local/bin (inspired by pipsi, bike-shedding wanted).

New config value install.prefix (bike-shedding wanted), for a default install path.

This is mainly to start discussion if this is a desired feature.

Lacking:

• tests
• error handling
• (possibly) windows support

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

[huonw]

Oooh, nice! I'm in favour of functionality like this.

Possible additional discussion points:

• this could maybe use a config option to set the default prefix.
• there's possibly something in the XDG directory spec (or something related) about where the default bin directory should be (http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html); it's not necessarily $HOME.

[globin]

• config option is definitely a good idea.
• the default installation path would normally be /usr/local/bin, but I'd normally prefer a user specific installation path, but that is definitely worth discussing. I'd like to hear more opinions on that.

To copy to e.g. /usr/local/bin it would be necessary to run cargo as root, right? I don't quite like having cargo running as root while compiling, but it isn't possible to switch to root at runtime?

[steveklabnik]

Certainly 👍 on cargo install

[tomaka]

Would the install command also cover downloading and installing a package from crates.io?

We don't want to reserve the install name for a command, only to discover later that another command would be more appropriate for this name.

[globin]

This is not covered at the moment but can be added backwards compatible as this command could simply take the crate name as a possible argument to install something from crates.io.

I definitely want to have that to but started with the local install as that is easier.

[alexcrichton]

Thanks for taking the initiative on this! I've definitely wanted functionality like this basically since the inception of Cargo! We've had a number of issues on this topic over time, and I definitely believe that this is quite a nuanced problem.

We're currently taking the stability of the cargo command line tool pretty seriously, so I don't think that we want to land a half-implementation just yet. There is currently no mechanism like feature gating for the command line interface unfortunately that rustc uses for language/library features. In its current form I think that there is still a good bit of work to be done, and I also think that I may not have a full picture of what needs to be done!

For example, I have some concerns here as well:

• Ideally one could cargo install foo to install something from crates.io
• One may also wish to cargo install /~https://github.com/foo/bar without having a permanent clone of the repository.
• Dynamic native dependencies do show up, and unfortunately they would pose a bit of a problem with the scheme of "just install the executable"
• Many packages/crates desire some form of post-installation logic. I am not personally aware of the use case for this, but the request has come up from time to time.
• There should probably be a method for reliable uninstallation of crates as well
• There should be a way to list installed executables
• Do we want to support installing libraries as well? Perhaps installing a Rust dynamic library with a C API?

The list goes on as well I imagine, and there are many other community members who I'm sure would have quite an opinion on this as well :). I would probably personally recommend pursuing this not on this PR but rather through the discuss forum or perhaps and RFC issue (or RFC itself). This form of new subcommand is likely to be hotly desired and we want to make sure we cover all our bases!

I'm not necessarily suggesting that this command needs to be 100% perfectly implemented just to land but rather that we need to be sure to design the command with all of these future use cases in mind. This may affect the choice of flags, for example, or perhaps influence some other decisions in other subcommands as well.

How does that all sound?

[bors]

☔ The latest upstream changes (presumably #1360) made this pull request unmergeable. Please resolve the merge conflicts.

[untitaker]

Many packages/crates desire some form of post-installation logic. I am not
personally aware of the use case for this, but the request has come up from
time to time.

I'd say that'd be simply out-of-scope for naively installing arbitrary software
through cargo.

There should probably be a method for reliable uninstallation of crates as
well

For this purpose, executables could stay in their target folders, and only be
symlinked into the paths (instead of copied, which seems to be the case ATM).
If the target folder is removed, all binaries of an application are removed,
and the dead symlinks are quite easy to clean up. This behavior is much more
similar to what pipsi does.

There should be a way to list installed executables

Not sure if that'd be useful enough to implement (additional bookkeeping). Listing
installed applications, OTOH, is pretty easy with the installation method
described above.

[comex]

Crazy idea - not totally on topic for this PR, but in general:

cargo install definitely sounds useful and should exist no matter what. But it would be nice if the common case, "I want to install the latest version of some public program X", didn't require the user to have yet another tool messing around in their /usr/local, to remember yet another syntax for listing installed packages, listing files in a package, finding the package corresponding to a file, upgrading packages, etc., etc.

Most of the kinds of users who would want to manually install Rust crates, however, likely already have some kind of package manager on their system. Linux users obviously almost universally have something; OS X power users usually have either Homebrew or MacPorts; I don't know how popular Chocolatey is on Windows, but it exists. Those users would probably appreciate being able to use their native package manager for Rust tools. Of course, relying on the distros themselves to package the tools is not good enough in a large number of cases, especially on Linux where users tend to run stable distros. And manually building packages for even a subset of those managers is a lot of work, c.f. the recent Reddit thread.

The crazy idea, therefore, is to run that infrastructure on crates.io - each supported OS/package manager would have a buildbot building all uploaded crates (hopefully in some reasonable sandbox), and automatically generate a web of native packages mirroring the original crates and dependencies. (Source-based package managers like the Mac ones, Portage, ... could get away without an actual buildbot if necessary, but dpkg/rpms need to be binary, and in any case it would be nice to have a bot alert you to compilation errors.) This would become the recommended way to install packages, and cargo's native support could remain minimal. As a bonus, binary distribution would decrease installation time, especially for the large programs of today and the future.

[Byron]

@comex I love the idea as well. Something I'd consider a prerequisite for this is

1. cross platform compilation of Rust programs (similar to what gox can do in the Go world)
   • this should work in most cases, but could get tricky in case there are 'dirty' dependencies to system libs. Nothing to worry about for the majority of the cases though
   • Cargo.toml could be used to provide more information, about asset files for instances that should be packaged as well. As cargo supports using arbitrary toolchains, that shouldn't be too much of a problem.
2. some library that can build native packages for various package managers. All reasonable package managers have some sort of specification, which can be produced by anyone.
   • again, Cargo.toml could be used to provide meta-data about how to produce certain package types. A mechanism to include other toml files could help to keep it clean.

With 1) in place I'd already be a happy man. With 2) in fact everyone can build packages for software deployment on your own platform. This is the key feature here - I don't want to use 10 VMs to build the program and create deployment packages.

Setting up a cloud-build-service that uses information of crates.io or another source will happen automatically, as it's a potential source for profit. If mozilla does it, even better, but external parties might have a shot at it earlier anyway.

[jan-hudec]

@comex, @Byron, I think the first step could be to teach cargo to invoke appropriate packager on the target machine. So on Debian it would write a bunch of files to the debian subdirectory and run dpkg-buildpackage, on RedHat it would write appropriate crate.spec and run rpmbuild, on Windows it would run something to build a .msi (Chocolatey is just repository; it seems to install from standard .msi or .exe installers) etc.

The install command could then try to run appropriate package manager (on Linux via sudo), while another subcommand (package?) would just build the package. Then a build server could be added to build the packages, so people could install even without having the development tools, but anybody who has rustc is quite likely to have, or be willing to install, the other developer tools too.

[steveklabnik]

This PR is now out of date and needs a rebase.

[globin]

I'm closing this for now because of lack of time. If anyone wants to pick up on this feel free to take this piece of code or do what you want to.