Cargo global package installation

[gsingh93]

In another post I realized that one of my annoyances with pulling dependencies for cargo is that the easiest way to use the dependencies is to switch to using the Cargo build system itself (instead of just plain old rustc). I don’t even know how to do it otherwise, I never used any dependencies pre-Cargo.

What I’d like (and I’m sure this has already been mentioned and discussed), is have some global package installation using Cargo, and then being able to access those crates with just an extern crate declaration. The code could still be built with just rustc file.rs with no extra command line flags.

If this is on the roadmap for Cargo, is it something planned for the near future or much later on? Are there any challenges that make this tricky and block it from being done currently, or are there simply more immediate tasks that need to be done before this?

[sinistersnare]

…why cant you just add dependencies to your Cargo.toml?

[gsingh93]

I can, but I don’t want to. Sometimes I just want to do simple stuff without cargo, maybe write a 100 line rust script to test something out. Creating a Cargo project just for that is kind of annoying.

I love that in python that if there’s some library I need to use, I can just do pip install foo and just start using foo in any python script in any project.

[gsingh93]

I can also imagine this will be useful when we have a proper rusti, like the python REPL.

[sinistersnare]

I was looking for the issue/rfcs-issue, but there has been talk about custom preludes lately, which may be what you are looking for.

[sinistersnare]

I can just do pip install foo and just start using foo in any python script in any project.

Note that having a global package installation like pip is definitely something Cargo avoids. Even the Python community frowns upon global installs, recommending the use of virtualenv for local dependencies…

[DanielKeep]

I don’t like “global package installation”, but I do like the idea of “global package caching”. It would be nice to not have to constantly re-build dependencies over and over again when building isolated libraries.

On a semi-unrelated note:

I was looking for the issue/rfcs-issue, but there has been talk about custom preludes lately, which may be what you are looking for.

Do you mean embedding the dependency information in the .rs itself? Because I’d love some sort of Rust script runner. It’s a bit of a pain to be helping someone on IRC/Reddit/SO and have to set up a new cargo package in a directory somewhere just to depend on something for a ten line program. Blah.

[gsingh93]

It’s a bit of a pain to be helping someone on IRC/Reddit/SO and have to set up a new cargo package in a directory somewhere just to depend on something for a ten line program.

It’s things like this why I want this feature. I agree 100% that when I’m developing some full blown python application I’ll use virtualenv, but in my day to day work I’m not. I’m writing scripts for myself (and only for myself), running certain computations in a REPL, or other tasks (like testing someones code on SO), and it’s nice I don’t have to do a whole virtualenv setup for python, but currently I have to do that for Rust.

I’d like to see this RFC that was mentioned. When I hear “custom preludes”, it doesn’t immediately seem like what I’m asking for.

[upsuper]

I guess an good compromise would be a global package cache and in-file dependency declaration.

I also have the requirement for small programs which I just don’t think they need an independent directory. But I do see the pain that a global package installation would have.

But in-file dependency declaration would solve both of them, the only problem is when and where should the dependencies be installed. That would need a global cache then.

Ideas?

[gsingh93]

This is supported now through an external script (it would be nice if there was some built in solution): https://github.com/DanielKeep/cargo-script

[DanielKeep]

I should note that cargo-script has made me want more aggressive caching even more.

I mean, the following program runs instantaneously, but takes sixteen seconds to fetch and build its dependencies, and it only directly depends on one crate. cargo-script can only do so much to help.

// cargo-deps: time="0.1.25"
extern crate time;
fn main() {
    println!("{}", time::now().rfc822z());
}

[vojtechkral]

Why don’t you use your distro’s package manager for this sort of thing? After all, that’s its prupose.

In that regard, it would by nice if rustc / cargo worked with package managers more seamlessly. For example, sometimes cargo projects won’t build when there’s a dependency already present in the system and cargo gets confised because it doesn’t know against which one to link (either local or system one).

[sanxiyn]

Why don’t you use your distro’s package manager for this sort of thing? After all, that’s its prupose.

Because rustc and cargo haven’t been properly packaged by distros yet. Packaging is in progress.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.