Skip to content

Add config-based path shorthands#9144

Closed
jonhoo wants to merge 4 commits into
rust-lang:masterfrom
jonhoo:path-shorthand
Closed

Add config-based path shorthands#9144
jonhoo wants to merge 4 commits into
rust-lang:masterfrom
jonhoo:path-shorthand

Conversation

@jonhoo

@jonhoo jonhoo commented Feb 6, 2021

Copy link
Copy Markdown
Contributor

When doing local development, users may wish to specify many path
dependencies that all live in the same local directory. If that local
directory is not a short distance from the Cargo.toml, this can get
unwieldy.

This patch introduces the notion of path "prefixes", which are defined
in .cargo/config.toml:

[base]
devdir = "/home/jon/dev/rust/"

Which can then be used as the root for path dependencies. For example:

foo = { path = "foo", base = "devdir" }
bar = { path = "bar", base = "devdir" }
baz = { path = "ws/baz", base = "devdir" }

would fetch foo from /home/jon/dev/rust/foo, bar from
/home/jon/dev/rust/bar, and baz from /home/jon/dev/rust/ws/baz.

This feature also serves as a convenient way for external build systems
to mask build-dependent paths from the user. Consider a build system
that vendors first-party dependencies into

/home/user/workplace/feature-1/build/first-party-package/first-party-package-1.0/x86_64/dev/build/private/rust-vendored/

Instead of requiring users to hard-code that path, or the relative
equivalent, into their Cargo.toml, the build-system can instead
produce a project-local .cargo/config.toml that defines that path as
base.vendored, and the user can then use vendored dependencies using

foo = { path = "foo", base = "vendored" }

@rust-highfive

Copy link
Copy Markdown

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 6, 2021
@jonhoo

This comment has been minimized.

@bjorn3

This comment has been minimized.

@ehuss

This comment has been minimized.

@bjorn3

This comment has been minimized.

When doing local development, users may wish to specify many `path`
dependencies that all live in the same local directory. If that local
directory is not a short distance from the `Cargo.toml`, this can get
unwieldy.

This patch introduces the notion of path "prefixes", which are defined
in `.cargo/config.toml`:

```toml
[path]
devdir = "/home/jon/dev/rust/"
```

Which can then be used as the root for path dependencies. For example:

```toml
foo = { path = "devdir::foo" }
bar = { path = "devdir::bar" }
baz = { path = "devdir::ws/baz" }
```

would fetch `foo` from `/home/jon/dev/rust/foo`, `bar` from
`/home/jon/dev/rust/bar`, and `baz` from `/home/jon/dev/rust/ws/baz`.

This feature also serves as a convenient way for external build systems
to mask build-dependent paths from the user. Consider a build system
that vendors first-party dependencies into

```
/home/user/workplace/feature-1/build/first-party-package/first-party-package-1.0/x86_64/dev/build/private/rust-vendored/
```

Instead of requiring users to hard-code that path, or the relative
equivalent, into their `Cargo.toml`, the build-system can instead
produce a project-local `.cargo/config.toml` that defines that path as
`path.vendored`, and the user can then use vendored dependencies using

```toml
foo = { path = "vendored::foo" }
```
@Eh2406

Eh2406 commented Feb 7, 2021

Copy link
Copy Markdown
Contributor

This is a very interesting approach! So far I think I like the idea. I think it will need an RFC before we can stabilize, and Team sign off before we merge.

@jonhoo

jonhoo commented Feb 8, 2021

Copy link
Copy Markdown
Contributor Author

I'd be happy to write up an RFC if there's a rough consensus from the team that an approach like this might be acceptable!

@jonhoo

jonhoo commented Feb 8, 2021

Copy link
Copy Markdown
Contributor Author

I had some time and wrote RFC 3074.

@bors

bors commented Feb 23, 2021

Copy link
Copy Markdown
Contributor

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

@bors

bors commented Mar 5, 2021

Copy link
Copy Markdown
Contributor

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

@ehuss

ehuss commented Aug 6, 2021

Copy link
Copy Markdown
Contributor

Closing as there is now an open RFC for this. Feel free to reopen after that has been accepted. Thanks!

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

Labels

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.

6 participants