-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Command alias or Alias command #1091 #2679
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #2396) made this pull request unmergeable. Please resolve the merge conflicts. |
989602d
to
a9d1aef
Compare
Thanks for the PR! The implementation looks pretty clean to me, I'd just probably elide the warning that you're using an alias and instead let it silently go through. Curious what others think about this though (cc @rust-lang/tools) |
Removed warning. thanks! |
Any more thoughts on this pull request? Thanks |
We discussed this in the tools subteam meeting and, as far as I remember, the consensus was that we are generally in favor of this idea. |
Ok, got a chance to talk about this some more with @wycats today as well (in addition to @rust-lang/tools). We were all somewhat ambivalent (neither here nor there on the feature), but some points brought up were:
|
Lets say my project has a .cargo/config Maybe the --list command can show that there is a sub-command and alias for debugging? |
I moved to a list for the alias and noticed a fun issue. I have a test file at the root of the project and in the test I create a test config. I found that the command list was being merged when I had overlapping alias. I think a non-merging get_list might be a good idea for this. Thoughts? |
dc477c5
to
c8ae752
Compare
default_alias.insert("t", "test".to_string()); | ||
default_alias.insert("r", "run".to_string()); | ||
let mut args: Vec<String> = env::args().collect(); | ||
let command = args[1].clone(); |
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.
Does this need to be cloned here? The if let
below I believe shouldn't borrow it for too long
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.
The clone is needed because I assign args[1] in the if block. Turns out I do not really need the command variable. I am now passing args[1] directly to the get.
Perhaps, yeah, although we'd probably want to specify the strategy when fetching the key of how to deal with duplicate arrays. The |
68819c3
to
ed12743
Compare
I was about done with the code when you said to ignore the quotes. Please checkout the regex code. It does not handle unbalanced quotes. I was thinking a warning "using an alias with unbalanced quotes. this may produce unexpected results please review your alias or ignore this message". since it is most likely an error case it should not come up often. I did spend some time trying to find the command line arg parser to reused but I could not find it. thanks again! |
☔ The latest upstream changes (presumably #2743) made this pull request unmergeable. Please resolve the merge conflicts. |
match value { | ||
Some(record) => { | ||
// Group quoted items together | ||
let regex = Regex::new("(\"[^\"]*\"|[^\"]+)").unwrap(); |
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.
Oh sorry, what I meant here was something like:
- If the configuration is a string, then we just split on whitespace
- We also accept a configuration of a list of strings, in which case we do not splitting. In that case I think we can avoid using a regex here
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 can support both string and list. I like the string regex because its more user friendly and what someone might expect. There is no easy feedback for the final command that is ran. If someone needed to use the list version it might be hard to debug why the string is failing. Should I keep the regex and support the list or figure out an easy way to display the command that is ran?
Feels very feature-creepy to me. Aliases are also something that can be solved in the shell. |
Ok. Thanks for the time. |
Let's not close just yet. Still worth considering closely. |
I was just looking at my gitconfig aliases. I was thinking about the usefulness of the current limitation and if the shell should handle the aliases. I think only one of my git aliases uses direct shell commands. Its not clear how I would personally use cargo alias other than to shorten names. I an see shell aliases that do more than just run cargo commands. If I would need to run more then one command would I bother with the cargo alias commands? I can see that running a custom build by default that lives outside the used shell scripts would be nice for consistency. I was thinking that the whole thing was "feature-creepy". Are you talking about something specific in the pull request is feature creep or the whole thing? |
Note that I don't consider this equivalent to shell aliases because they crucially can't do what this PR is doing. A shell alias typically takes a non-whitespace-separated string (e.g. I also use git aliases all the time (e.g. |
Sorry I got distracted. @alexcrichton you would like me to move back to the list version of the config and drop the string splitting or support both? Thanks again |
@sbeckeriv at minimum we should support a string list and then I think it's also optional that we could support string configuration which is only split on spaces. |
17c15f8
to
2d0a587
Compare
Updated. Both now string and list works. I removed the regex that tried to not split quoted parts of a string. If someone needs more complex splitting they can fall back to the list version. Thanks again. I have learned a lot! |
@@ -186,6 +207,31 @@ fn execute(flags: Flags, config: &Config) -> CliResult<Option<()>> { | |||
Ok(None) | |||
} | |||
|
|||
fn list_of_alias_commands(config: &Config, command: &String) -> Option<Vec<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'll want to return a CargoResult
of the output so malformed configuration can be printed as well.
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 see. If the alias is an float for example. The code current ignores that.
Thanks! I will sort this out. I think I want to use a CargoResult<Option<Vec<_>>>
.
Thanks @sbeckeriv! The implementation looks good to me. @brson do you have specific concerns you're worried about that you could elaborate on? |
@alexcrichton No. |
b4c167b
to
681ef6c
Compare
Dearest Reviewer, This pull request closes rust-lang#1091 which is a request to support aliases. This is not as powerful as something like git's alias, however, I think it sticks true to the original request. I high jack the processing of the args. After a few flags are checked and the args are parsed I check the config file for alias.COMMAND. If it is there I split it like args does and replace args[1] (the original command) with the alias command and its 'flags'. I have also included default short hand commands b, t and r. Thanks! Becker
@alexcrichton Thanks. I added a test for the mismatched type error. I updated the docs to include the defaults, a list example and a white space example. I was unsure of a good place to document the default aliases. Should I update the usage message? Something like: Also I don't know what changed but building cargo on nightly is blazing fast! The broken up test are also way faster! |
@bors: r+ Ok cool, thanks @sbeckeriv! I think we may want to explore documenting this in the --help messages eventually, but for now let's see how this plays out in terms of rolling it out first. Thanks again for keeping up with the PR! |
📌 Commit 66739f1 has been approved by |
Command alias or Alias command #1091 Dearest Reviewer, This pull request closes #1091 which is a request to support aliases. This is not as powerful as something like git's alias, however, I think it sticks true to the original request. I high jack the processing of the args. After a few flags are checked and the args are parsed I check the config file for alias.COMMAND. If it is there I split it like args does and replace args[1] (the original command) with the alias command and its 'flags'. As an extra measure I output the alias command with warn. I would be willing to drop that or put it behind a verbose flag. Also the docs have been updated. Thanks! Becker <img width="784" alt="screen shot 2016-05-12 at 10 23 59 am" src="https://cloud.githubusercontent.com/assets/12170/15226012/d18a3336-1835-11e6-94c9-875a63a79856.png">
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
Dearest Reviewer,
This pull request closes #1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.
I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1](the original
command) with the alias command and its 'flags'.
As an extra measure I output the alias command with warn. I would be
willing to drop that or put it behind a verbose flag. Also the docs have
been updated.
Thanks!
Becker