Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow installing a package from outside a manifest #37

Closed
cmr opened this issue Jun 24, 2014 · 7 comments

Comments

Projects
None yet
5 participants
@cmr
Copy link
Member

commented Jun 24, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2014

Can you say what workflow you would like for this?

@cmr

This comment has been minimized.

Copy link
Member Author

commented Jun 26, 2014

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

@cmr

This comment has been minimized.

Copy link
Member Author

commented Jun 26, 2014

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

@untitaker

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2015

That'd be #1318

@icorderi

This comment has been minimized.

Copy link

commented May 8, 2015

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 (#557 and later on #1318): package already exists but not as described in those threads.
  • cargo install foobar (#1318, #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

This comment has been minimized.

Copy link
Member

commented May 14, 2015

@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

This comment has been minimized.

Copy link
Member

commented Nov 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.