Git Product home page Git Product logo

Comments (7)

icorderi avatar icorderi commented on May 22, 2024 1

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.

from cargo.

wycats avatar wycats commented on May 22, 2024

Can you say what workflow you would like for this?

from cargo.

emberian avatar emberian commented on May 22, 2024

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

from cargo.

emberian avatar emberian commented on May 22, 2024

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

from cargo.

untitaker avatar untitaker commented on May 22, 2024

That'd be #1318

from cargo.

alexcrichton avatar alexcrichton commented on May 22, 2024

@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.

from cargo.

alexcrichton avatar alexcrichton commented on May 22, 2024

Implemented as cargo install!

from cargo.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.