Executor

Latest version: v23.1

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

Scan your dependencies

Page 2 of 18

21.1

----------------------------

Improve compatibility with "vanilla Ubuntu 18.04 docker images" by parsing the
file ``/etc/lsb-release`` when the program ``/usr/bin/lsb_release`` isn't
installed (fixes `10`_).

This enables the ``distributor_id`` and ``distribution_codename`` properties to
work even when the ``/usr/bin/lsb_release`` program isn't installed, by parsing
the ``/etc/lsb-release`` file instead. Tested on Ubuntu 14.04, 16.04 and 18.04.

.. _Release 21.1: https://github.com/xolox/python-executor/compare/21.0...21.1
.. _10: https://github.com/xolox/python-executor/issues/10

21.0

----------------------------

**Implemented Python 3.7 compatibility.**

Python 3.7 was released in June 2018 and introduced the reserved keyword
``async`` which made the definition of the ``ExternalCommand.async``
property a syntax error. Should have seen that coming 😒.

In any case, due to personal circumstances I haven't had time for any open
source programming in the past few months which meant feedback on this issue
piled up in the form of issue `9`_ and pull requests `11`_ and `13`_:

- Pull request `11`_ proposed switching to ``_async``.
- Pull request `13`_ proposed switching to ``asynchronous``.

Apart from the naming difference both pull requests represented the same
change, however I prefer ``asynchronous`` over ``_async`` because I have a
strong dislike for leading and trailing underscores that have no semantic value
except to avoid using a reserved keyword (I'm looking at you SQLAlchemy 😛).

There was one thing that bugged me about all of this though: While it was clear
that ``ExternalCommand.async`` needed to be renamed I didn't feel like breaking
backwards compatibility with lots of existing Python 2 code using executor with
the old ``async`` naming. That's why I've updated the code to programatically
add an ``async`` alias that defers to the real ``asynchronous`` property.
Because this is done using the ``setattr()`` function no reserved keywords are
harmed in the process 😇.

I've also added Python 3.7 to the supported and tested Python releases.

.. _Release 21.0: https://github.com/xolox/python-executor/compare/20.0.1...21.0
.. _9: https://github.com/xolox/python-executor/issues/9
.. _11: https://github.com/xolox/python-executor/pull/11
.. _13: https://github.com/xolox/python-executor/pull/13

20.0.1

------------------------------

- Bug fix: Merged pull request `14`_ to make ``ionice_command`` compatible
with older ``ionice`` versions not supporting the ``--class`` option.

- Lots of commit noise to debug Python 2.6 support on Travis CI. I'm not sure
why I still bother...

.. _Release 20.0.1: https://github.com/xolox/python-executor/compare/20.0...20.0.1
.. _14: https://github.com/xolox/python-executor/pull/14

20.0

----------------------------

*While intended to be fully backwards compatible (because the new behavior is
opt-in) I decided to bump the major version number in this release because
adding retry support touched on some of the most critical pieces of code in
this project.*

- Experimental support for retrying of commands that fail. Retrying of
asynchronous commands is only supported in the context of command pools.
- Bug fix: Pass keyword arguments of ``wait()`` to ``wait_for_process()``.
- Fix Sphinx warnings (mostly broken references).

Notes about retry support
~~~~~~~~~~~~~~~~~~~~~~~~~

I've been wanting to add retry support to `executor` for quite a while now. One
thing that I struggled with until recently was how to support retrying of
synchronous and asynchronous commands in a way that made sense for both types
of commands, without compromising too much on the simplicity of the Python API
or the actual implementation code.

In a pragmatic *"just implement something and see how it works"* moment I
decided to add support for retrying of synchronous commands to the
``ExternalCommand`` class while requiring the use of a command pool to retry
asynchronous commands. Although this implementation doesn't cover every
possible use case I do believe it covers the most important use cases. Some
high-level implementation notes:

- Synchronous commands are retried inside of the ``start()`` method. The second
part of this method was extracted into a new ``start_once()`` method and then
a loop was added to ``start()`` that calls ``start_once()`` until the command
succeeds.

- Asynchronous commands allow for retry behavior to be configured but won't
actually run a command more than once unless used in the context of command
pools. I did experiment with retrying of asynchronous commands inside the
``wait()`` method but this ended up creating an API whose behavior was very
unintuitive (changing its behavior from non blocking to blocking in order to
retry on failure).

.. _Release 20.0: https://github.com/xolox/python-executor/compare/19.3...20.0

19.3

----------------------------

- Added ``SecureTunnel`` class for easy to use SSH tunnels (``ssh -NL ...``).
- Added ``RemoteCommand.compression`` property to enable ``ssh -C``.
- Extracted generic TCP functionality from the ``executor.ssh.server`` module
into a new ``executor.tcp`` module (so that the functionality could be reused
by the new SSH tunnel support).

.. _Release 19.3: https://github.com/xolox/python-executor/compare/19.2...19.3

19.2

----------------------------

- Added a ``glob()`` method to contexts (this was triggered
by the feature request in `rotate-backups issue 10
<https://github.com/xolox/python-rotate-backups/issues/10>`_).
- Improved documentation using ``property_manager.sphinx``.
- Added this changelog, restructured the online documentation.
- Include documentation in source distributions.
- Added ``license`` key to ``setup.py`` script.

.. _Release 19.2: https://github.com/xolox/python-executor/compare/19.1...19.2

Page 2 of 18

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.