The @action decorator should capture all the exceptions,
log them and return them on `Response.errors`.
This ensures that uncaught exceptions from plugin
actions won't unwind out of control, and also that they
are logged and treated consistently across all the
integrations.
If we include the class name by default then we won't have to
explicitly modify the client_id in the implementation classes
in order to prevent clashes.
- Do `abspath`+`expanduser` on the configuration file path before
checking if it exists.
- If the path doesn't exist, but the user explicitly passed a
configuration file, then copy/create the default configuration
under the specified directory.
The new configuration:
- Enables `backend.http` by default
- Removes the extra `config.auto.yaml` dependency
- Includes many more examples, lots of updates for existing examples,
and extensive comments.
Following some common UNIX conventions, if no configuration file is
specified and none exists under the default locations, then a new
configuration directory should be created under:
```
- if root: /etc/platypush
- else:
- if XDG_CONFIG_HOME:
- $XDG_CONFIG_HOME/platypush
- else:
- ~/.config/platypush
```
The two scripts now share the same command interface, behaviour and base
class.
Also, Platydock now builds a Docker image instead of just printing a
Dockerfile, unless the `--print` option is passed.
Instead of having a custom `get_installed` callable field, with
replicated code for each package manager, the field has now been
promoted to a class method containing the common logic, and the
instances now expect a `list` field (base command to list the installed
packages using the specified package manager) and a `parse_list_line`
callback field (to extract the base package name given a raw line from
the command above).
Also, we shouldn't run the list command if we're running within a Docker
context - the host and container environments will be different.