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

Make search the default subcommand #12

Closed
dbgrandi opened this issue Apr 27, 2014 · 10 comments · Fixed by #13
Closed

Make search the default subcommand #12

dbgrandi opened this issue Apr 27, 2014 · 10 comments · Fixed by #13

Comments

@dbgrandi
Copy link
Contributor

With @AliSoftware adding the search subcommand we could make that the default and change the behavior of search to list all the plugins unless you pass in an optional regex to search with.

pod plugins would list out all the plugins

and

pod plugins neonichu would list any plugins that @neonichu authors.

Thoughts?

@AliSoftware
Copy link
Contributor

Sounds great to me. Actually as I added the search command I thought about it and even thought about accepting an empty query, making it list all plugins in that case, so I'm all good for this.

@neonichu
Copy link
Member

👍

@AliSoftware
Copy link
Contributor

Still thinking that pod plugins neonichu shouldn't list plugins authored by neonichu unless we specify the --full flag to specifically tell to search in the 'author' field.

This would ensure consistency with pod search behavior, searching only in the plugin 's 'name' field if we don't use --full.

@dbgrandi
Copy link
Contributor Author

Good point, and I agree with you. Bad example on my part. Let me rephrase that second one...

pod plugins stat would show any plugin with to stat in the name.

@fabiopelosin
Copy link
Member

Wow @AliSoftware sweating the details!

@AliSoftware
Copy link
Contributor

@irrationalfab always 😉

@dbgrandi
Copy link
Contributor Author

Is it weird that a valid search this week (e.g. pod plugins popular) could end up doing something different (and possibly destructive) next week if we add new subcommands?

I'm trying to think of another unix command that follows this pattern (first positional arg can be a named subcommand if it exists or input to the default command) and I can't think of one off the top of my head.

@AliSoftware, you've got me overthinking the details now! 😄

@AliSoftware
Copy link
Contributor

Agreed, I was thinking the same thing. Maybe setting search as the default subcommand whereas it can take arguments was not such a good idea after all.

This gives more and more credit to @irrationalfab 's suggestion of having a separate list subcommand (taking no argument, and being the new default subcommand) in addition to the search subcommand.

I vote for pod plugins list being the new default and rollbacking to pod plugins search QUERY having its parameter mandatory again. Thoughts?

@AliSoftware, you've got me overthinking the details now! 😄

hehehe

@neonichu
Copy link
Member

@AliSoftware Sounds good.

@AliSoftware
Copy link
Contributor

Done! (new commits in #13)

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 a pull request may close this issue.

4 participants