Skip to content

[WIP] feat(cargo-vendor): vendor path dep if it is not in any given workspaces#13347

Closed
weihanglo wants to merge 1 commit intorust-lang:masterfrom
weihanglo:vendor-path-deps
Closed

[WIP] feat(cargo-vendor): vendor path dep if it is not in any given workspaces#13347
weihanglo wants to merge 1 commit intorust-lang:masterfrom
weihanglo:vendor-path-deps

Conversation

@weihanglo
Copy link
Member

What does this PR try to resolve?

feat(cargo-vendor): vendor path dep if it is not in any given workspaces

Generally cargo don't vendor path dependencies.
This seems quiet reasonable path dependencies are "local" comparing
to git or registry dependencies, and usually under the user's control.
However, it is not always the case.

A workspace might contain

  • any [patch] to local path dependencies
  • a set of shared path dependencies outside the current workspace

These use cases demonstrate that users might not have controls or
permissions to those dependencies. When they want to create a
reproducible tarball for their own workspace, cargo vendor is not a
tool helping them achieve the goal.

There is one workaround: Have a [patch] to a local git repository
instead of a lcoal path dependency. This is not ergonomic and adds
overhead of setting git repositories.

This PR proposes that Cargo vendors path dependencies if they are
not belong to any given workspaces.

As a side effect, this exposes a new [source] kind path:

[source."path+file:///path/to/package"]
path = "/path/to/package"
replace-with = "vendored-sources"

How should we test and review this PR?

This is a proof-of-concept, not ready for serious code review.

Additional information

An alternative to #12858
Fixes #9172
Possibly also #10134, but I am not sure if they intend to vendor workspace members.

@rustbot
Copy link
Collaborator

rustbot commented Jan 25, 2024

r? @epage

(rustbot has picked a reviewer for you, use r? to override)

Generally cargo don't vendor path dependencies.
This seems quiet reasonable path dependencies are "local" comparing
to git or registry dependencies, and usually under the user's control.
However, it is not always the case.

A workspace might contain

* any `[patch]` to local path dependencies
* a set of shared path dependencies outside the current workspace

These use cases demonstrate that users might not have controls or
permissions to those dependencies. When they want to create a
reproducible tarball for their own workspace, `cargo vendor` is not a
tool helping them achieve the goal.

There is one workaround: Have a `[patch]` to a local git repository
instead of a lcoal path dependency. This is not ergonomic and adds
overhead of setting git repositories.

This PR proposes that Cargo vendors path dependencies if they are
not belong to any given workspaces.

As a side effect, this exposes a new  `[source]` kind `path`:

```toml
[source."path+file:///path/to/package"]
path = "/path/to/package"
replace-with = "vendored-sources"
```
@weihanglo
Copy link
Member Author

This is just a proof-of-concept so going to close. Further discussion should happen in #9172 or #10134.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Command-vendor S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cargo vendor with patch section and local sources does not vendor the local files

3 participants