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.

Log message:
py-wrapt: updated to 1.14.1

Version 1.14.1

Bugs Fixed

When the post import hooks mechanism was being used, and a Python package with \ 
its own custom module importer was used, importing modules could fail if the \ 
custom module importer didn't use the latest Python import hook finder/loader \ 
APIs and instead used the deprecated API. This was actually occurring with the \ 
zipimporter in Python itself, which was not updated to use the newer Python APIs \ 
until Python 3.10.

Log message:
py-wrapt: updated to 1.14.0

Version 1.14.0

Bugs Fixed

Python 3.11 dropped inspect.formatargspec() which was used in creating signature \ 
changing decorators. Now bundling a version of this function which uses \ 
Parameter and Signature from inspect module when available. The replacement \ 
function is exposed as wrapt.formatargspec() if need it for your own code.
When using a decorator on a class, isinstance() checks wouldn’t previously \ 
work as expected and you had to manually use Type.__wrapped__ to access the real \ 
type when doing instance checks. The __instancecheck__ hook is now implemented \ 
such that you don’t have to use Type.__wrapped__ instead of Type as last \ 
argument to isinstance().
Eliminated deprecation warnings related to Python module import system, which \ 
would have turned into broken code in Python 3.12. This was used by the post \ 
import hook mechanism.

New Features

Binary wheels provided on PyPi for aarch64 Linux systems and macOS native \ 
silicon where supported by Python when using pypa/cibuildwheel.

Log message:
*: bump PKGREVISION for egg.mk users

They now have a tool dependency on py-setuptools instead of a DEPENDS

Log message:
py-wrapt: updated to 1.13.3

Version 1.13.3

New Features

Adds wheels for Python 3.10 on PyPi and where possible also now generating \ 
binary wheels for musllinux.

Log message:
archivers: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes

Could not be committed due to merge conflict:
devel/py-traitlets/distinfo

The following distfiles were unfetchable (note: some may be only fetched
conditionally):

./devel/pvs/distinfo pvs-3.2-solaris.tgz
./devel/eclipse/distinfo eclipse-sourceBuild-srcIncluded-3.0.1.zip

Log message:
py-wrapt: updated to 1.13.2

Version 1.13.2

Features Changed

On the Windows platform when using Python 2.7, by default the C extension will \ 
not be installed and the pure Python implementation will be used. This is \ 
because too often on Windows when using Python 2.7, there is no working compiler \ 
available. Prior to version 1.13.0, when installing the package it would \ 
fallback to using the pure Python implementation automatically but that relied \ 
on a workaround to do it when there was no working compiler. With the changes in \ 
1.13.0 to use the builtin mechanism of Python to not fail when a C extension \ 
cannot be compiled, this fallback doesn't work when the compiler doesn't exist, \ 
as the builtin mechanism in Python regards lack of a compiler as fatal and not a \ 
condition for which it is okay to ignore the fact that the extension could not \ 
be compiled.

If you are using Python 2.7 on Windows, have a working compiler, and still want \ 
to attempt to install the C extension, you can do so by setting the \ 
WRAPT_INSTALL_EXTENSIONS environment variable to true when installing the wrapt \ 
package.

Note that the next signficant release of wrapt will drop support for Python 2.7 \ 
and Python 3.5. The change described here is to ensure that wrapt can be used \ 
with Python 2.7 on Windows for just a little bit longer. If using Python 2.7 on \ 
non Windows platforms, it will still attempt to install the C extension.