Tuesday, September 03, 2024

Re: archivers/py-zstandard: improve tests

On 2024/09/03 14:38, Kirill A. Korinsky wrote:
> On Tue, 03 Sep 2024 10:56:10 +0200,
> Stuart Henderson <stu@spacehopper.org> wrote:
> >
> > If you can find a way, it would be much better if this could be handled
> > in python.port.mk than individual ports, it should be the same for any
> > ports using a certain MODPY_PYBUILD type (at least those that have .so
> > extensions).
> >
> > It feels like there should be a way to set PYTHONPATH etc to avoid the
> > mess of copying/linking but I didn't hit upon it yet...
>
> I tried to find a generic way to fix it. But as far as I know, we have three
> ports affected by this problem: net/synapse, archivers/py-zstandard and
> devel/py-uvloop.

There are way more affected - some workaround by using different
MODPY_TEST_DIR, some by using a test wrapper from upstream or a
pre-test command to set things up, some are just broken. And some
ports with python .so extensions work as-is without extra changes.

"pkglocate .so|grep ^py3-|cut -d: -f2|sort -u" will find various
of these ..

> The first one uses poetry-core, and the others use setuptools. This means it
> doesn't MODPY_PYBUILD specified.
>
> The first two use rust inside, and the last one doesn't. So, neither does
> this.

setuptools ports should usually specify MODPY_PYBUILD. Maybe there is
some exception for messy rust+python ports. But even if there's just
something to help more non-rust setuptools ports work it would avoid
a lot of the pain.

What's there now (MODPY_TEST_LIBDIR default) is mostly a result of
running into failures and finding PYTHONPATH changes that allow them
to work.

> The best generic solution I have in mind is another variable that allows to
> find what links or moves .so; but it looks pretty ugly, isn't it?

The tree layout under the library build dir should be the same as the
layout shouldn't it? So if it does need to move/link (which would be
ugly itself) at least it maybe possible to use a sane default without
setting another var...

No comments:

Post a Comment