-
Notifications
You must be signed in to change notification settings - Fork 71
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 aliases #290
Command aliases #290
Conversation
if String.contains?(name, ":") do | ||
:identity | ||
else | ||
case Repo.all(Command.bundle_for(name)) do |
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.
Since bundle names trump alias names do we prevent users from creating aliases which conflict with installed bundles? What happens when a user creates an alias and later a bundle with a conflicting name is installed?
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.
Maybe we do something like when an unqualified command name is not authoritative (i.e., "You typed foo
, but we don't know if you meant foo:foo
or bar:foo
")
Perhaps we need a way to unambiguously note that something is an alias? (alias:foo
, though that prevents there ever being a bundle named alias
...)
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.
If memory serves, returning a SemanticError
from the old BundleResolver
with a reason of :ambiguous_command
would generate such an error message. Based on what I've read so far I believe we preserve the behavior.
As a reasonably helpful and not entirely difficult first step we could send a warning message to the user whenever they execute an alias which shadows a bundle.
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.
What's the best path to accomplish that? The only thing I can think of is querying for aliases on every command invocation. Is there a more efficient way?
23916c4
to
de10d8d
Compare
{:ok, %Ast.Pipeline{}=pipeline} -> | ||
maybe_warn_on_ambiguous_aliases(pipeline, state) |
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.
@kevsmith @christophermaier Any thoughts on this? If a command is executed with an ambiguous alias we send a warning to the user. It's a bit odd because we query for aliases on every command invocation, and it won't trigger if the user passes the fully qualified name for the alias. implementation is on L#809 and in the Lib.Command.AmbiguousAliasChecker
module.
8cbd35a
to
59e002f
Compare
Assuming current build is green I'm 👍 to merge. |
This enables command aliases.
resolves #260
dependent on operable/piper#8
dependent on operable/piper#9