The previous commit prompted a new error:
```
2024-06-01 10:54:08,310|ERROR|platypush:plugin:bluetooth|module 'platypush.entities.time' has no attribute 'time'
Traceback (most recent call last):
File "/usr/lib/python3.9/dist-packages/platypush/plugins/__init__.py", line 247, in _runner
self.main()
File "/usr/lib/python3.9/dist-packages/platypush/plugins/bluetooth/__init__.py", line 590, in main
self._refresh_cache()
File "/usr/lib/python3.9/dist-packages/platypush/plugins/bluetooth/__init__.py", line 146, in _refresh_cache
get_entities_engine().wait_start()
File "/usr/lib/python3.9/dist-packages/platypush/entities/__init__.py", line 48, in get_entities_engine
time_start = time.time()
AttributeError: module 'platypush.entities.time' has no attribute 'time'
```
Which explains even the previous error: `import time` in that module
won't use the `time` module from the Python library, but the `.time`
module within the same directory.
This error only happens when the current directory is part of PYTHONPATH
(and usually it shouldn't), but for sake of keeping things safe I've
replaced `time()` with `utcnow().timestamp()`, with `utcnow` imported
from `platypush.utils`.
```
Traceback (most recent call last):
File "/usr/lib/python3.9/dist-packages/platypush/plugins/__init__.py", line 247, in _runner
self.main()
File "/usr/lib/python3.9/dist-packages/platypush/plugins/bluetooth/__init__.py", line 590, in main
self._refresh_cache()
File "/usr/lib/python3.9/dist-packages/platypush/plugins/bluetooth/__init__.py", line 146, in _refresh_cache
get_entities_engine().wait_start()
File "/usr/lib/python3.9/dist-packages/platypush/entities/__init__.py", line 48, in get_entities_engine
time_start = time()
TypeError: 'module' object is not callable
```
There isn't a single reason in this world for this error to happen.
If I do `from time import time`, then `t = time()` is 100% valid Python.
I have no clue of what may be causing it, but I hope that this will fix
it.
No need to maintain two different pieces of logic - a `utcnow()` for
Python < 3.11 and `now(datetime.UTC)` for Python >= 3.11.
`datetime.timezone.utc` existed long before datetime.UTC and that's what
the `utcnow` facade should use.
This means that all the `utcnow()` will always have `tzinfo=UTC`
regardless of the Python version.
There's still a problem with the `utcnow()`-generated timestamps that
have been generated by previous versions of Python and stored on the db.
Therefore, when the code performs comparisons with timestamps fetched
from the db, it should always explicitly do a `.replace(tzinfo=utc)` to
ensure that we always compare offset-aware datetime representations.
See blog post for technical details:
https://manganiello.blog/wheres-my-time-again
The new API no longer returns a list of numeric values alone. Instead,
it returns a tuple where the first element is the raw audio, and the
second element contains extra info on the rendered phonemes.
`datetime.utcnow` may be deprecated on Python >= 3.12, but
`datetime.UTC` isn't present on older Python versions.
Added a `platypush.utils.utcnow()` method as a workaround compatible
with both.
`assistant` contains the assistant plugin object that triggered the
event, but you can't create event hook conditions on attributes that are
plugins.
The event should also store a `plugin` attribute which contains the
unique plugin name, so hooks like these can be built:
```
from platypush import hook
from platypush.events.assistant import ConversationStartEvent
@when(ConversationStartEvent, plugin="assistant.google")
def on_google_conversation_start():
...
```
It wouldn't be possible to construct a hook condition like the one above
on the plugin object reported on the `assistant` attribute.
Even though `platypush.events` is just a symlink to
`platypush.message.event`, imports from those two modules will be
treated as different imports, thus hook conditions build on
`platypush.events` imports will never match.
This fixes the case where Platydock is called within the context of a
virtual environment, but it needs to generate a Docker image - and
therefore, unless the host virtual environment, it needs
--break-system-packages to write to /usr.
If the Platypush setup.py is found in the current directory, then use
that directory as the base for the new image.
Otherwise, clone the repo on the fly and build the image from there.
All the latest versions of Alpine, Debian, Ubuntu and Fedora now require
`--break-system-packages` when installing packages via `pip` outside of
a virtual environment, even if it's within a container.
Fabio Manganiello