add command line wrapper

[cthoyt]

Check setuptools guide and add simple command line script to wrap pushover_complete

• get secret keys from env or pass with argument?
• use click or argparse?

[scolby33]

I envision a configuration like this, in order of priority:

1. Provided command-line arguments, which override
2. A config file passed in via command line (i.e. -c file/location), which overrides
3. Set environment variables, which override
4. The config file located in the default location (.conf/something on *nix and somewhere reasonable on Windows), which overrides
5. Built-in default options

(2) and (3) could reasonably be switched...the order of those is a judgement call. Comments on that?

Despite my love for JSON, I think an ini-style config should be used here:

[pushover_complete:default]
TOKEN=....
USER=...
etc.

[pushover_complete:my_special_setting1]
DEVICE=...
TITLE=...
etc.

[pushover_complete:my_special_setting2]
USER=...
DEVICE=...
etc.

So if you call the CLI with default arguments, it'll read the config file's default section. If you call it and tell it you want to use my_special_setting2, it applies the default settings from the config and then overrides them with whatever is in the chosen setting.

Perhaps the configuration should be implemented as a dictionary that gets update()'d by all available configuration sources in order?

[cthoyt]

Glad you mentioned it. I didn't really have in mind what you'd be doing with the cli wrapper, but it could be part of all sorts of other scripts so this sounds good. I like the order of 2 and 3 because 3 and 4 are automatically set while 2 will be explicit when its executed.

I don't care one way or another for INI or JSON. This actually looks nice. I've never done INI in python but I'd assume there's a good decoder library? It's an easy enough data structure

[scolby33]

I agree that (1) and (2) are explicitly provided and (3) generally would just be hanging out, but you can have constructions like this TOKEN=1234 command_line_app --option whatever that sets the environment variable just for that invocation. That's probably uncommon though, and the precedence can be documented, so I'm sure it'll be fine.

configparser is what you want.

Upon further reflection, it might be confusing for options set in the default config to propagate up even when a different config is passed via the command line. So maybe only one config file is read at a time? Or it has to be well-documented. I think some standard tools do this though...
Compare sshd:

sshd(8) reads configuration data from /etc/ssh/sshd_config (or the file specified with -f on the command line).

To ssh:

ssh(1) obtains configuration data from the following sources in the following order:

1. command-line options
2. user's configuration file (~/.ssh/config)
3. system-wide configuration file (/etc/ssh/ssh_config)

For each parameter, the first obtained value will be used.

The latter is what I am proposing.

[cthoyt]

also good point, I agree. are we nixing environment variables?

[scolby33]

It depends. Is there an argument that using an environment variable would be significantly more convenient than passing an argument every time (that couldn't be solved just by creating your own variable and passing it with $VAR)? This assumes you have a reason not to create a dedicated config file.

I'm leaning towards yes, skip the environment entirely, just use configs and command-line arguments.

[tlevine]

It looks like horetu does half of what you want for argument and configuration parsing. It doesn't support the full complexity of configuration fallbacks that you request, and it does not have Python 2.7 support. I would be happy to add either of those as I have been thinking about doing both anyway, but it wouldn't happen especially soon.

[scolby33]

That's a cool package you've written there! I'm not sure how @cthoyt plans on finishing his implementation, but I'll definitely keep it in mind for CLI projects I work on!

[scolby33]

Some comments on the design of the CLI. I'll start with full invocations and neglect the use of configs for now:

$ pushover $TOKEN $USER $MESSAGE  # should these be arguments (positional) or options (--whatever)
$ # they're not technically optional...
$ # also, if it's workable, it would be cool if "send" were implied

For the other commands, you'd have things like

$ pushover $TOKEN sounds
$ pushover $TOKEN validate $USER --device $DEVICE
$ pushover $TOKEN receipt $RECEIPT
$ pushover $TOKEN migrate $USER $SUBSCRIPTION --device $DEVICE --sound $SOUND
$ pushover $TOKEN group $GROUP_KEY
$ pushover $TOKEN group add $GROUP $USER --device $DEVICE --memo $MEMO  # should this be `group add` sub command, or something different?
$ pushover $TOKEN group delete $GROUP $USER  # possibly bad naming, are you deleting the group or the user from the group?
$ pushover $TOKEN group disable $GROUP $USER
$ pushover $TOKEN group enable $GROUP $USER
$ pushover $TOKEN group rename $GROUP $NEW_NAME
$ pushover $TOKEN assign $USER

Sending a message does kinda have a ridiculous number of options...

$ pushover $TOKEN $USER $MESSAGE --device $DEVICE --title $TITLE --url $URL\
> --url-title $URL_TITLE --priority $PRIORITY --retry $RETRY --expire $EXPIRE\
> --callback-url $CALLBACK_URL --timestamp $TIMESTAMP --sound $SOUND --html  # --html is boolean, so only need to check for presence

Last comment--need to normalize the name of the multi-word options e.g. url-title vs url_title: which should be the name used in the config files?

[cthoyt]

It would be nice to default the pushover commmand to send, but it's always going to look for a command after pushover. The pushover group could also have all the same options and if they're there, just call send, but that's not elegant at all and will look like a mess in the code and the docs.

I guess this will have to work for the group options though