Log message:
devel/py-wrapt: use atomic64.mk to fix build with python3.13 on macppc.

Log message:
py-wrapt: updated to 1.17.2

Version 1.17.2

New Features

Added universal binary wheels for macOS. That is, contains both x86_64 and arm64 \ 
architectures in the same wheel.

Log message:
py-wrapt: updated to 1.17.1

1.17.1

Bugs Fixed

Due to GitHub actions changes, binary wheels were missing for macOS Intel.
Not implemented error for __reduce__() on ObjectProxy was incorrectly displaying \ 
the error as being on __reduce_ex__().

Log message:
py-wrapt: updated to 1.17.0

Version 1.17.0

Note that version 1.17.0 drops support for Python 3.6 and 3.7. Python version \ 
3.8 or later is required.

New Features

Add __format__() method to ObjectProxy class to allow formatting of wrapped object.
Added C extension internal flag to indicate that wrapt should be safe for Python \ 
3.13 free threading mode. Releases will include free threading variants of \ 
Python wheels. Note that as free threading is new, one should be cautious about \ 
using it in production until it has been more widely tested.

Bugs Fixed

When a normal function or builtin function which had wrapt.decorator or a \ 
function wrapper applied, was assigned as a class attribute, and the function \ 
attribute called via the class or an instance of the class, an additional \ 
argument was being passed, inserted as the first argument, which was the class \ 
or instance. This was not the correct behaviour and the class or instance should \ 
not have been passed as the first argument.
When an instance of a callable class object was wrapped which didn't not have a \ 
__get__() method for binding, and it was called in context whhere binding would \ 
be attempted, it would fail with error that __get__() did not exist when instead \ 
it should have been called directly, ignoring that binding was not possible.
The __round__ hook for the object proxy didn't accept ndigits argument.

Log message:
py-*: remove unused tool dependency

py-setuptools includes the py-wheel functionality nowadays

Log message:
py-wrapt: convert to wheel.mk

Bump PKGREVISION.

Log message:
py-wrapt: updated to 1.16.0

wrapt-1.16.0
Unknown changes

Log message:
py-wrapt: updated to 1.15.0

Version 1.15.0

Bugs Fixed

When the C extension for wrapt was being used, and a property was used on an \ 
object proxy wrapping another object to intercept access to an attribute of the \ 
same name on the wrapped object, if the function implementing the property \ 
raised an exception, then the exception was ignored and not propagated back to \ 
the caller. What happened instead was that the original value of the attribute \ 
from the wrapped object was returned, thus silently suppressing that an \ 
exception had occurred in the wrapper. This behaviour was not happening when the \ 
pure Python version of wrapt was being used, with it raising the exception. The \ 
pure Python and C extension implementations thus did not behave the same.

Note that in the specific case that the exception raised is AttributeError it \ 
still wouldn't be raised. This is the case for both Python and C extension \ 
implementations. If a wrapper for an attribute internally raises an \ 
AttributeError for some reason, the wrapper should if necessary catch the \ 
exception and deal with it, or propagate it as a different exception type if it \ 
is important that an exception still be passed back.

Address issue where the post import hook mechanism of wrapt wasn't transparent \ 
and left the __loader__ and __spec__.loader attributes of a module as the wrapt \ 
import hook loader and not the original loader. That the original loader wasn't \ 
preserved could interfere with code which needed access to the original loader.

Address issues where a thread deadlock could occur within the wrapt module \ 
import handler, when code executed from a post import hook created a new thread \ 
and code executed in the context of the new thread itself tried to register a \ 
post import hook, or imported a new module.

When using CallableObjectProxy as a wrapper for a type or function and calling \ 
the wrapped object, it was not possible to pass a keyword argument named self. \ 
This only occurred when using the pure Python version of wrapt and did not occur \ 
when using the C extension based implementation.

When using PartialCallableObjectProxy as a wrapper for a type or function, when \ 
constructing the partial object and when calling the partial object, it was not \ 
possible to pass a keyword argument named self. This only occurred when using \ 
the pure Python version of wrapt and did not occur when using the C extension \ 
based implementation.

When using FunctionWrapper as a wrapper for a type or function and calling the \ 
wrapped object, it was not possible to pass a keyword argument named self. \ 
Because FunctionWrapper is also used by decorators, this also affected \ 
decorators on functions and class types. A similar issue also arose when these \ 
were applied to class and instance methods where binding occurred when the \ 
method was accessed. In that case it was in BoundFunctionWrapper that the \ 
problem could arise. These all only occurred when using the pure Python version \ 
of wrapt and did not occur when using the C extension based implementation.

When using WeakFunctionProxy as a wrapper for a function, when calling the \ 
function via the proxy object, it was not possible to pass a keyword argument \ 
named self.