YAML isn't part of the Python standard library, while JSON is.
If we want `setup.py` to dynamically parse the available integration
manifest files in order to populate the extra dependencies, then it's
better to rely on a JSON format for manifest files - the parser is part
of the standard library and it doesn't require the user to install
`pyyaml` before `platypush`.
The old type configuration
(`platypush.plugins.calendar.name.CalendarNamePlugin`) is a bit clunky.
Instead, since the type will always be a plugin, we should encourage
the use of `calendar.name` directly to identify the type.
continuous-integration/drone/push Build is passingDetails
Added an `add_dependencies` plugin to the Sphinx build process that
parses the manifest files of the scanned backends and plugins and
automatically generates the documentation for the required dependencies
and triggered events.
This means that those dependencies are no longer required to be listed
in the docstring of the class itself.
Also in this commit:
- Black/LINT for some integrations that hadn't been touched in a long
time.
- Deleted some leftovers from previous refactors (deprecated
`backend.mqtt`, `backend.zwave.mqtt`, `backend.http.request.rss`).
- Deleted deprecated `inotify` backend - replaced by `file.monitor` (see
#289).
continuous-integration/drone/push Build is passingDetails
- If a Python optional dependency is available as a system package on
the target system, try and install it that route rather than pip. It's
usually faster and it decreases the risk of breaking system packages.
- Added support for apk dependencies in manifest files. This brings the
number of distros officially supported by all the extensions to four:
- Alpine
- Arch
- Debian
- Ubuntu
The error should not be swallowed and it should be instead propagated up
to calendar.get_upcoming_events, if it's called from that context. And
calendar.get_upcoming_events should be in charge of handling the
exceptions and make sure that failing to retrieve the events for one
calendar doesn't make the whole method fail.
- Using `@action` annotation to indicate methods that are allowed to be
executed as actions
- The output and errors of an action are automatically wrapped into a
`Response` object without any response build required on the plugin side
Fabio Manganiello
Fabio Manganiello