-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Allow cargo aliases to shadow existing commands with flags #9768
Conversation
r? @Eh2406 (rust-highfive has picked a reviewer for you, use r? to override) |
since it's related to #9767 |
d4f3097
to
e3ca6c4
Compare
@@ -73,6 +76,56 @@ fn recursive_alias() { | |||
.run(); | |||
} | |||
|
|||
#[cfg(unix)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cfg(unix) because I use a small bash program in the test.
Open to other ideas. Just needed a small program which echoed back out args.
} | ||
|
||
already_expanded.push(cmd.to_string()); | ||
if already_expanded.contains(&new_cmd.to_string()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
happy to switch to a LinkedHashMap if we want cargo to support O(n*log(n)) resolution of dependent aliases instead of O(n^2). I figured n is probably small, and linked_hash_map crate is a new dependency - but happy to switch it if preferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why LinkedHashMap
over indexmap
? But yes n is probably to small for it to matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wasn't familiar with indexmap - looks great to me.
It still appears that it would be an additional dependency to cargo (not sure if you want to pull it in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine for now, yeah, and if it's an issue there's a number of other data structures to use here instead.
4d45bb6
to
5f8b329
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me, thanks! Would you be ok updating the documentation for the alias section as well?
.executable( | ||
Path::new("subcommands").join("cargo-test-1"), | ||
r#" | ||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a shell script, would you be up for updating this test to build a small cargo project that produces a binary that does the same thing? We do that in a few other places in the test suite as well, primarily for Windows testing support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a place where this happens and refactored it into cargo-test-support/src/tools.rs
} | ||
|
||
already_expanded.push(cmd.to_string()); | ||
if already_expanded.contains(&new_cmd.to_string()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine for now, yeah, and if it's an issue there's a number of other data structures to use here instead.
4bfaee8
to
9687a9b
Compare
|
Thanks! This affects the public API of cargo so I'm gonna ask for sign-off from others as well: @rfcbot fcp merge |
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I'm slightly concerned that it may be confusing to people what "built-in" means, since we don't define that anywhere. To many users, they perceive I guess there's also some concerns about why built-in commands are blessed in such a way that they can't be overridden. Why are they that much different from third-party commands? There are legitimate reasons why this is not allowed for built-in commands, so why would third-party commands be different? This could introduce some future compatibility hazards. For example, if someone has an alias I guess, I'd like to see an explanation of why these are different. |
Re: Concern - builtins are blessed Good point. I believe disallowing aliases on builtin commands was an idea stolen from git. Here's an SO Post It doesn't elaborate much on why. There's a benefit to disallowing aliasing of builtins away entirely - users confusing themselves out of fundamental commands. Aliasing with default args seems more ok. Perhaps it needn't be blessed for the default-args use case.
Re: Concern - compatibility hazard I think this compatibility hazard is preexisting. There's always the risk of adding a new builtin command - which can mess with people's aliases and custom subcommands. I think it's just the cost of adding a new builtin (it won't be backward compatible). I know that appealing to the preexisting nature of the issue is not the best argument/defense - so consider it an opportunity to reconsider, but probably we'd have to think about how to handle subcommand / builtin conflicts as well. |
Another issue is that tools invoke Cargo commands as part of build processes, and such aliases could disrupt automated builds. As far as I can tell, we don't even have an option to ignore a user's This is of course also a problem for other commands such as I'd also hate to see a crate trying to override |
@rfcbot concern breaking-automated-usage |
I pulled out the non-controversial majority of this diff into #9791 - simply ensuring that we give a reasonable error message instead of stack-overflow when there are recursively defined aliases. Assuming that one can get in with less discussion, then we can have the discussion here on a smaller diff.
Great point - another reason to lean toward disallowing default-flags on builtin commands (or potentially disallowing default-flags entirely). |
9687a9b
to
6e5574a
Compare
Eg. [alias] test-1 = test-2 test-2 = test-3 test-3 = test-1 Previously it would stack overflow It pulls out non controversial bits from from rust-lang#9768
Teach cargo to failfast on recursive/corecursive aliases Eg. [alias] test-1 = test-2 test-2 = test-3 test-3 = test-1 Previously it would stack overflow Pulled out non controversial bits from from #9768
☔ The latest upstream changes (presumably #9791) made this pull request unmergeable. Please resolve the merge conflicts. |
Teaches cargo to accept default-args aliases of the form [alias] fmt = fmt --verbose Disallows this on builtins. Fixes rust-lang#8360
6e5574a
to
2173224
Compare
We discussed this in today's @rust-lang/cargo meeting. We came to the conclusion that we really want to have consistency between internal and external cargo commands, so we don't want to allow aliases to override either one. (We'd be happy to have improvements to the error messages for overriding external commands, though.) |
Thanks @joshtriplett, @alexcrichton and all. Appreciated. Consider giving the explanation on the tracking issue #8360 as well (and closing it)! |
Teaches cargo to accept default-args aliases of the form
[alias]
fmt = fmt --verbose
Teaches cargo to failfast (rather than stack overflow on corecursive
aliases)
[alias]
test-1 = test-2
test-2 = test-3
test-3 = test-1
Fixes #8360