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

Local patch(s) with remote in published copy. #7519

Closed
cheako opened this issue Oct 16, 2019 · 3 comments
Closed

Local patch(s) with remote in published copy. #7519

cheako opened this issue Oct 16, 2019 · 3 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@cheako
Copy link

cheako commented Oct 16, 2019

This(B) comes from(A) not wanting linting fmt/clippy to descend into feather from hazel-feather. See https://www.reddit.com/r/rust/comments/dimku2/crate_patching_and_fmtclippy/

The goal(A) is to have hazel-feather depend on a patched and volatile feather, that isn't linted recursively.

The goal(B) is to git push something anyone can build where [patch.crates-io] references git/remote. While at the same time having [patch.crates-io] references a path/local.

On Unix ~/.cargo/overrides has something like:

[hazel-feather.patch.crates-io.feather]
path = "../feather"

https://gitlab.com/cheako/hazel-feather/blob/77e70dbc9f760964df2ae66048032c5a3be3f388/Cargo.toml

The example takes any source where name = "hazel-feather". Might be better to use path to identify where to apply the override. For this project it's expected that feather will be edited a lot and it isn't good to have to push to gitlab for every change.

@cheako cheako added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Oct 16, 2019
@ehuss
Copy link
Contributor

ehuss commented Oct 18, 2019

I'm having a hard time understanding the request here. If I'm understanding correctly:

  • You want to patch some dependencies, and you point the patches at a git repo.
  • While doing development, you want to patch those dependencies to a local path.
    • And you don't want those local paths included with clippy or rustfmt.

I think maybe #5539 could be a solution where you could have local patches that are in .cargo/config.

I think the work being done in #7382 to change the way clippy works should help address the issue with clippy running on all dependencies.

AFAIK, rustfmt does not run on patches.

Does that sound correct?

@cheako
Copy link
Author

cheako commented Oct 18, 2019

@ehuss Close.

  • You want to patch some dependencies, and you point the patches at a git repo.
    • And you don't want those patches included with clippy or rustfmt. This is working, the point here is for CI we want the clippy info for just this crate... As opposed to what you get with a git submodule and "local path"
  • While doing development, you want to patch those dependencies to a local path.
    • And you can't stop those local paths included with clippy or rustfmt. This is OK as I'd be hacking on both crates I'd want this feature/bug. Edit: OK either way, it's not needed and doesn't hurt.

Yes, #5539 looks perfect. I'll keep my eyes out for an updated clippy, thanks.

@ehuss
Copy link
Contributor

ehuss commented Nov 8, 2019

OK, I think I'll close this in favor of the other issues.

@ehuss ehuss closed this as completed Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

No branches or pull requests

2 participants