Log message:
py-*: remove unused tool dependency

py-setuptools includes the py-wheel functionality nowadays

Log message:
py-anyio: update to 4.6.2.post1.

- Fixed regression caused by (`#807 \ 
<https://github.com/agronholm/anyio/pull/807>`_)
  that prevented the use of parametrized async fixtures

Log message:
py-anyio: updated to 4.6.2

4.6.2

- Fixed regression caused by
  that prevented the use of parametrized async fixtures

4.6.1

This release contains all the changes from both v4.5.1 and v4.6.0, plus:

- Fixed TaskGroup and CancelScope producing cyclic references in tracebacks
  when raising exceptions

Log message:
py-anyio: update to 4.6.0.

Dropped support for Python 3.8 (as #698 cannot be resolved without cancel \ 
message support)
Fixed 100% CPU use on asyncio while waiting for an exiting task group to finish \ 
while said task group is within a cancelled cancel scope (#695)
Fixed cancel scopes on asyncio not propagating CancelledError on exit when the \ 
enclosing cancel scope has been effectively cancelled (#698)
Fixed asyncio task groups not yielding control to the event loop at exit if \ 
there were no child tasks to wait on
Fixed inconsistent task uncancellation with asyncio cancel scopes belonging to a \ 
task group when said task group has child tasks running

Log message:
py-anyio: updated to 4.4.0

**4.4.0**

- Added the ``BlockingPortalProvider`` class to aid with constructing synchronous
  counterparts to asynchronous interfaces that would otherwise require multiple \ 
blocking
  portals
- Added ``__slots__`` to ``AsyncResource`` so that child classes can use \ 
``__slots__``
- Added the ``TaskInfo.has_pending_cancellation()`` method
- Fixed erroneous ``RuntimeError: called 'started' twice on the same task status``
  when cancelling a task in a TaskGroup created with the ``start()`` method before
  the first checkpoint is reached after calling ``task_status.started()``
- Fixed two bugs with ``TaskGroup.start()`` on asyncio:

  * Fixed erroneous ``RuntimeError: called 'started' twice on the same task status``
    when cancelling a task in a TaskGroup created with the ``start()`` method before
    the first checkpoint is reached after calling ``task_status.started()``
  * Fixed the entire task group being cancelled if a ``TaskGroup.start()`` call gets
    cancelled
- Fixed a race condition that caused crashes when multiple event loops of the same
  backend were running in separate threads and simultaneously attempted to use \ 
AnyIO for
  their first time
- Fixed cancellation delivery on asyncio incrementing the wrong cancel scope's
  cancellation counter when cascading a cancel operation to a child scope, thus \ 
failing
  to uncancel the host task
- Fixed erroneous ``TypedAttributeLookupError`` if a typed attribute getter raises
  ``KeyError``
- Fixed the asyncio backend not respecting the ``PYTHONASYNCIODEBUG`` environment
  variable when setting the ``debug`` flag in ``anyio.run()``
- Fixed ``SocketStream.receive()`` not detecting EOF on asyncio if there is also \ 
data in
  the read buffer
- Fixed ``MemoryObjectStream`` dropping an item if the item is delivered to a \ 
recipient
  that is waiting to receive an item but has a cancellation pending
- Emit a ``ResourceWarning`` for ``MemoryObjectReceiveStream`` and
  ``MemoryObjectSendStream`` that were garbage collected without being closed
- Fixed ``MemoryObjectSendStream.send()`` not raising ``BrokenResourceError`` \ 
when the
  last corresponding ``MemoryObjectReceiveStream`` is closed while waiting to send a
  falsey item

Log message:
py-anyio: updated to 4.3.0

4.3.0

Added support for the Python 3.12 walk_up keyword argument in \ 
anyio.Path.relative_to()

Fixed passing total_tokens to anyio.CapacityLimiter() as a keyword argument not \ 
working on the trio backend

Fixed Process.aclose() not performing the minimum level of necessary cleanup \ 
when cancelled. Previously:

Cancellation of Process.aclose() could leak an orphan process
Cancellation of run_process() could very briefly leak an orphan process.
Cancellation of Process.aclose() or run_process() on Trio could leave standard \ 
streams unclosed

Fixed Process.stdin.aclose(), Process.stdout.aclose(), and \ 
Process.stderr.aclose() not including a checkpoint on asyncio

Fixed documentation on how to provide your own typed attributes

Log message:
py-anyio: updated to 4.2.0

4.2.0

- Add support for ``byte``-based paths in ``connect_unix``, \ 
``create_unix_listeners``,
  ``create_unix_datagram_socket``, and \ 
``create_connected_unix_datagram_socket``. (PR by
  Lura Skye)
- Enabled the ``Event`` and ``CapacityLimiter`` classes to be instantiated outside an
  event loop thread
- Broadly improved/fixed the type annotations. Among other things, many functions and
  methods that take variadic positional arguments now make use of PEP 646
  ``TypeVarTuple`` to allow the positional arguments to be validated by static type
  checkers. These changes affected numerous methods and functions, including:

  * ``anyio.run()``
  * ``TaskGroup.start_soon()``
  * ``anyio.from_thread.run()``
  * ``anyio.from_thread.run_sync()``
  * ``anyio.to_thread.run_sync()``
  * ``anyio.to_process.run_sync()``
  * ``BlockingPortal.call()``
  * ``BlockingPortal.start_task_soon()``
  * ``BlockingPortal.start_task()``

- Fixed various type annotations of ``anyio.Path`` to match Typeshed:

  * ``anyio.Path.__lt__()``
  * ``anyio.Path.__le__()``
  * ``anyio.Path.__gt__()``
  * ``anyio.Path.__ge__()``
  * ``anyio.Path.__truediv__()``
  * ``anyio.Path.__rtruediv__()``
  * ``anyio.Path.hardlink_to()``
  * ``anyio.Path.samefile()``
  * ``anyio.Path.symlink_to()``
  * ``anyio.Path.with_segments()``

- Fixed adjusting the total number of tokens in a ``CapacityLimiter`` on asyncio \ 
failing
  to wake up tasks waiting to acquire the limiter in certain edge cases (fixed \ 
with help
  from Egor Blagov)
- Fixed ``loop_factory`` and ``use_uvloop`` options not being used on the asyncio
  backend
- Fixed cancellation propagating on asyncio from a task group to child tasks if \ 
the task
  hosting the task group is in a shielded cancel scope

Log message:
py-anyio: updated to 4.1.0

4.1.0

- Adapted to API changes made in Trio v0.23:

  - Call ``trio.to_thread.run_sync()`` using the ``abandon_on_cancel`` keyword \ 
argument
    instead of ``cancellable``
  - Removed a checkpoint when exiting a task group
  - Renamed the ``cancellable`` argument in ``anyio.to_thread.run_sync()`` to
    ``abandon_on_cancel`` (and deprecated the old parameter name)
  - Bumped minimum version of Trio to v0.23
- Added support for voluntary thread cancellation via
  ``anyio.from_thread.check_cancelled()``
- Bumped minimum version of trio to v0.23
- Exposed the ``ResourceGuard`` class in the public API
- Fixed ``RuntimeError: Runner is closed`` when running higher-scoped async generator
  fixtures in some cases
- Fixed discrepancy between ``asyncio`` and ``trio`` where reraising a cancellation
  exception in an ``except*`` block would incorrectly bubble out of its cancel scope

Log message:
python/wheel.mk: simplify a lot, and switch to 'installer' for installation

This follows the recommended bootstrap method (flit_core, build, installer).

However, installer installs different files than pip, so update PLISTs
for all packages using wheel.mk and bump their PKGREVISIONs.

Log message:
py-anyio: updated to 4.0.0

**4.0.0**

- **BACKWARDS INCOMPATIBLE** Replaced AnyIO's own ``ExceptionGroup`` class with \ 
the PEP
  654 ``BaseExceptionGroup`` and ``ExceptionGroup``
- **BACKWARDS INCOMPATIBLE** Changes to cancellation semantics:

  - Any exceptions raising out of a task groups are now nested inside an
    ``ExceptionGroup`` (or ``BaseExceptionGroup`` if one or more \ 
``BaseException`` were
    included)
  - Fixed task group not raising a cancellation exception on asyncio at exit if \ 
no child
    tasks were spawned and an outer cancellation scope had been cancelled before
  - Ensured that exiting a ``TaskGroup`` always hits a yield point, regardless of
    whether there are running child tasks to be waited on
  - On asyncio, cancel scopes will defer cancelling tasks that are scheduled to \ 
resume
    with a finished future
  - On asyncio and Python 3.9/3.10, cancel scopes now only suppress cancellation
    exceptions if the cancel message matches the scope
  - Task groups on all backends now raise a single cancellation exception when \ 
an outer
    cancel scope is cancelled, and no exceptions other than cancellation \ 
exceptions are
    raised in the group
- **BACKWARDS INCOMPATIBLE** Changes the pytest plugin to run all tests and \ 
fixtures in
  the same task, allowing fixtures to set context variables for tests and other \ 
fixtures
- **BACKWARDS INCOMPATIBLE** Changed ``anyio.Path.relative_to()`` and
  ``anyio.Path.is_relative_to()`` to only accept one argument, as passing multiple
  arguments is deprecated as of Python 3.12
- **BACKWARDS INCOMPATIBLE** Dropped support for spawning tasks from old-style \ 
coroutine
  functions (``@asyncio.coroutine``)
- **BACKWARDS INCOMPATIBLE** The ``policy`` option on the ``asyncio`` backend was
  changed to ``loop_factory`` to accommodate ``asyncio.Runner``
- Changed ``anyio.run()`` to use ``asyncio.Runner`` (or a back-ported version of \ 
it on
  Pythons older than 3.11) on the ``asyncio`` backend
- Dropped support for Python 3.7
- Added support for Python 3.12
- Bumped minimum version of trio to v0.22
- Added the ``anyio.Path.is_junction()`` and ``anyio.Path.walk()`` methods
- Added ``create_unix_datagram_socket`` and \ 
``create_connected_unix_datagram_socket`` to
  create UNIX datagram sockets (PR by Jean Hominal)
- Fixed ``from_thread.run`` and ``from_thread.run_sync`` not setting sniffio on \ 
asyncio.
  As a result:

  - Fixed ``from_thread.run_sync`` failing when used to call sniffio-dependent \ 
functions
    on asyncio
  - Fixed ``from_thread.run`` failing when used to call sniffio-dependent \ 
functions on
    asyncio from a thread running trio or curio
  - Fixed deadlock when using \ 
``from_thread.start_blocking_portal(backend="asyncio")``
    in a thread running trio or curio (PR by Ganden Schaffner)
- Improved type annotations:

  - The ``item_type`` argument of ``create_memory_object_stream`` was deprecated.
    To indicate the item type handled by the stream, use
    ``create_memory_object_stream[T_Item]()`` instead. Type checking should no longer
    fail when annotating memory object streams with uninstantiable item types (PR by
    Ganden Schaffner)
- Added the ``CancelScope.cancelled_caught`` property which tells users if the cancel
  scope suppressed a cancellation exception
- Fixed ``fail_after()`` raising an unwarranted ``TimeoutError`` when the cancel \ 
scope
  was cancelled before reaching its deadline
- Fixed ``MemoryObjectReceiveStream.receive()`` causing the receiving task on \ 
asyncio to
  remain in a cancelled state if the operation was cancelled after an item was \ 
queued to
  be received by the task (but before the task could actually receive the item)
- Fixed ``TaskGroup.start()`` on asyncio not responding to cancellation from the \ 
outside
- Fixed tasks started from ``BlockingPortal`` not notifying synchronous listeners
  (``concurrent.futures.wait()``) when they're cancelled
- Removed unnecessary extra waiting cycle in ``Event.wait()`` on asyncio in the case
  where the event was not yet set
- Fixed processes spawned by ``anyio.to_process()`` being "lost" as \ 
unusable to the
  process pool when processes that have idled over 5 minutes are pruned at part \ 
of the
  ``to_process.run_sync()`` call, leading to increased memory consumption