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

Add config-based path shorthands #9144

Closed
wants to merge 4 commits into from

Conversation

jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Feb 6, 2021

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

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
Copy link
Contributor

Eh2406 commented Feb 7, 2021

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
Copy link
Contributor Author

jonhoo commented Feb 8, 2021

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
Copy link
Contributor Author

jonhoo commented Feb 8, 2021

I had some time and wrote RFC 3074.

@bors
Copy link
Collaborator

bors commented Feb 23, 2021

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

@bors
Copy link
Collaborator

bors commented Mar 5, 2021

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

@ehuss
Copy link
Contributor

ehuss commented Aug 6, 2021

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.

None yet

6 participants