Huey

Latest version: v2.5.0

Safety actively analyzes 628903 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 3 of 8

2.1.2

Not secure
* Allow `AsyncResult` object used in `MiniHuey` to support the `__call__()`
method to block and resolve the task result.
* When running the django `run_huey` management command, the huey loggers will
not be configured if another logging handler is already registered to the
huey namespace.
* Added experimental contrib storage engine using `kyoto tycoon <http://fallabs.com/kyototycoon>`_
which supports task priority and the option to do automatic result
expiration. Requires the `ukt <https://github.com/coleifer/ukt>`_ python
package and a custom kyototycoon lua script.
* Allow the Sqlite storage engine busy timeout to be configured when
instantiating `SqliteHuey`.

[View commits](https://github.com/coleifer/huey/compare/2.1.1...2.1.2)

2.1.1

Not secure
* Ensure that `task()`-decorated functions retain their docstrings.
* Fix logger setup so that the consumer log configuration is only applied to
the `huey` namespace, rather than the root logger.
* Expose `result`, `signal` and `disconnect_signal` in the Django huey
extension.
* Add `SignedSerializer`, which signs and validates task messages.
* Refactor the `SqliteStorage` so that it can be more easily extended to
support other databases.

[View commits](https://github.com/coleifer/huey/compare/2.1.0...2.1.1)

2.1.0

Not secure
* Added new contrib module `sql_huey`, which uses `peewee <https://github.com/coleifer/peewee>`_
to provide storage layer using any of the supported databases (sqlite, mysql
or postgresql).
* Added `RedisExpireHuey`, which modifies the usual Redis result storage logic
to use an expire time for task result values. A consequence of this is that
this storage implementation must keep all result keys at the top-level Redis
keyspace. There are some small changes to the storage APIs as well, but will
only possibly affect maintainers of alternative storage layers.
* Also added a `PriorityRedisExpireHuey` which combines the priority-queue
support from `PriorityRedisHuey` with the result-store expiration mechanism
of `RedisExpireHuey`.
* Fix gzip compatibility issue when using Python 2.x.
* Add option to `Huey` to use `zlib` as the compression method instead of gzip.
* Added `FileStorageMethods` storage mixin, which uses the filesystem for task
result-store APIs (put, peek, pop).
* The storage-specific `Huey` implementations (e.g. `RedisHuey`) are no longer
subclasses, but instead are partial applications of the `Huey` constructor.

[View commits](https://github.com/coleifer/huey/compare/2.0.1...2.1.0)

2.0.1

Not secure
* Small fixes, fixed typo in Exception class being caught by scheduler.

[View commits](https://github.com/coleifer/huey/compare/2.0.0...2.0.1)

2.0.0

Not secure
This section describes the changes in the 2.0.0 release. A detailed list of
changes can be found here: https://huey.readthedocs.io/en/latest/changes.html

Overview of changes:

* `always_eager` mode has been renamed to `immediate` mode. Unlike previous
versions, `immediate` mode involves the same code paths used by the consumer
process. This makes it easier to test features like task revocation and task
scheduling without needing to run a dedicated consumer process. Immediate
mode uses an in-memory storage layer by default, but can be configured to use
"live" storage like Redis or Sqlite.
* The events stream API has been removed in favor of simpler callback-driven
[signals](https://huey.readthedocs.io/en/latest/signals.html) APIs. These
callbacks are executed synchronously within the huey consumer process.
* A new serialization format is used in 2.0.0, however consumers running 2.0
will continue to be able to read and deserialize messages enqueued by Huey
version 1.11.0 for backwards compatibility.
* Support for [task priorities](https://huey.readthedocs.io/en/latest/guide.html#task-priority).
* New `Serializer` abstraction allows users to customize the serialization
format used when reading and writing tasks.
* Huey consumer and scheduler can be more easily run within the application
process, if you prefer not to run a separate consumer process.
* Tasks can now specify an `on_error` handler, in addition to the
previously-supported `on_complete` handler.
* Task pipelines return a special `ResultGroup` object which simplifies reading
the results of a sequence of task executions.
* `SqliteHuey` has been promoted out of `contrib`, onto an equal footing with
`RedisHuey`. To simplify deployment, the dependency on
[peewee](https://github.com/coleifer/peewee) was removed and the Sqlite
storage engine uses the Python `sqlite3` driver directly.

[View commits](https://github.com/coleifer/huey/compare/1.11.0...2.0.0)

1.11.0

Not secure
**Backwards-incompatible changes**

Previously, it was possible for certain tasks to be silently ignored if a task
with that name already existed in the registry. To fix this, I have made two
changes:

1. The task-name, when serialized, now consists of the task module and the name
of the decorated function. So, "queue_task_foo" becomes "myapp.tasks.foo".
2. An exception will be raised when attempting to register a task function with
the same module + name.

Together, these changes are intended to fix problems described in 386.

Because these changes will impact the serialization (and deserialization) of
messages, **it is important that you consume all tasks (including scheduled
tasks) before upgrading**.

**Always-eager mode changes**

In order to provide a more consistent API, tasks enqueued using `always_eager`
mode will now return a dummy `TaskResultWrapper` implementation that wraps the
return value of the task. This change is designed to provide the same API for
reading task result values, regardless of whether you are using always-eager
mode or not.

Previously, tasks executed with `always_eager` would return the Python value
directly from the task. When using Huey with the consumer, though, task results
are not available immediately, so a special wrapper `TaskResultWrapper` is
returned, which provides helper methods for retrieving the return value of the
task. Going forward, `always_eager` tasks will return `EagerTaskResultWrapper`,
which implements the same `get()` API that is typically used to retrieve task
return values.

[View commits](https://github.com/coleifer/huey/compare/1.10.5...1.11.0)

Page 3 of 8

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.