Closed stuartpb closed 10 years ago
Actually --app
should only be interpreted before the command name, in case somebody implements a plugin that forwards whatever options you give it to something else, and that something else has a --app
flag.
Last app flag wins, so pluchu
should specify the default --app
option before anything specified on the command line.
This also raises something of an issue to me: it means users now need to be aware whether their client is auto-inserting --app
because that changes the signature of the parameters they need to specify (unless they specify --app
manually which defeats the whole purpose).
Also this is totally an option and not a flag. Derp. I should rename the project ASAP.
(project renamed from plushu-app-flag
to plushu-app-long-opt
, going through an awkward plushu-app-opt-plugin
phase where I hadn't thought of the distinction)
Wait, crap: plushu/plushu#29
I think my original idea for implementing this was to filter based on the command, and then either shift one or two from the argument based on whether the given plugin was registered as an "app-conscious" command via plushook.
However, now that I think about it, the smarter way to work it would be to specify a PLUSHU_APP environment variable when this flag is set, and then any app commands can check that variable for an alternative to $2. (This means many commands dealing with apps may need to change the way they set their options.)
The reasoning behind why this plugin would be useful is as an extension to plushu/pluchu - pluchu could automatically add the "--app" arguments based on the target of the remote, letting it work like the implicit "--app" value in the Heroku toolbelt, without breaking non-app commands like
help
orplugins:install
.It's also for that reason that we would only be checking for
--app
and not-a
- commands should be free to specify their own short options (although we could maybe catch-a
in the space before the command).