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

Command aliases #290

Closed
wants to merge 7 commits into from
Closed

Command aliases #290

wants to merge 7 commits into from

Conversation

mpeck
Copy link
Contributor

@mpeck mpeck commented Feb 23, 2016

This enables command aliases.

resolves #260
dependent on operable/piper#8
dependent on operable/piper#9

@mpeck mpeck changed the title Command aliases (WIP) Command aliases Feb 24, 2016
if String.contains?(name, ":") do
:identity
else
case Repo.all(Command.bundle_for(name)) do
Copy link
Member

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?

Copy link
Collaborator

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...)

Copy link
Member

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.

Copy link
Contributor Author

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?

@mpeck mpeck force-pushed the peck/alias-execution branch from 23916c4 to de10d8d Compare February 24, 2016 22:29
{:ok, %Ast.Pipeline{}=pipeline} ->
maybe_warn_on_ambiguous_aliases(pipeline, state)
Copy link
Contributor Author

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.

@mpeck mpeck force-pushed the peck/alias-execution branch from 8cbd35a to 59e002f Compare February 25, 2016 21:05
@kevsmith
Copy link
Member

Assuming current build is green I'm 👍 to merge.

@mpeck mpeck closed this Feb 25, 2016
@mpeck mpeck deleted the peck/alias-execution branch February 25, 2016 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Command alias executor wiring
3 participants