[go: up one dir, main page]
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.

Sign up for GitHub

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

Jump to bottom

Allow separating implicit dependencies in cargo vendor #11178

Open
iCodeSometime opened this issue Oct 6, 2022 · 2 comments
Open

Allow separating implicit dependencies in cargo vendor #11178

iCodeSometime opened this issue Oct 6, 2022 · 2 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@iCodeSometime
Copy link
iCodeSometime commented Oct 6, 2022 •
edited
Loading

Problem

When viewing vendored crates manually, I am most interested in crates I've explicitly added as a dependency.

It would be convenient if explicit dependencies were in the top level vendor folder, and implicit dependencies were in a subfolder.

Since cargo already supports multiple sources, it seems at first glance like this wouldn't require any major changes to support

Proposed Solution

A new option for cargo vendor (maybe --organize-implicit)

This option would

  1. Add any dependencies in cargo.toml to the main vendor directory (or whatever path was passed in)
  2. Create a subfolder (maybe _deps) for any dependencies not explicitly referenced in cargo.toml
  3. Display an updated version of the "add this to your .cargo/config.toml" guidance to include adding the _deps directory as a package source

Notes

Possible naming clash if e.g. a package named _deps were created (none exist now)
@iCodeSometime iCodeSometime added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Oct 6, 2022
@weihanglo
Copy link
Member

Thank you for the idea!

This feature seems quite interesting and convenient, though personally I feel like it fits more implemented as an IDE/editor plugin. Imagine you are browsing Cargo.toml and click "Jump to source" button, and you're there. Also, for vendoring a workspace and maybe nested workspaces in the future, I don't know how to interact with them. Do we really want to see all direct dependencies of each workspace members at the same top level? Do we want to manage it more granularly for creating more subdirectories? Everyone has their own preference to reading stuff. I am not sure where we are going. For personal preference, I always choose the route of creating an IDE plugin.

This feature might also stack up the already intricate implementation complexity. It might aslo be hard to interact with #10344 if in the future we pick it up. I am sorry that we currently have limited capacity on either designing this feature or reviewing any pull request for it 😞

For naming clashes, technically your concern does exist. As #10344 (comment) mentioned, it depends on what we choose eventually for crate namespacing, it would be a hazard if we decide to add some subdirectories with special meaning that conflicts with their choice.

@iCodeSometime
Copy link
Author

Alright, thanks for the feedback! The ability to jump to source from cargo.toml is definitely an interesting alternative.

I'll check if there's any interest in rust-analyzer for adding cargo.toml support in general.

@weihanglo weihanglo mentioned this issue Oct 10, 2022
Closed
@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@epage @iCodeSometime @weihanglo