.egg-info for entry points during dh_auto_test

[Michael Fladischer]

Hi,

I'm working on src:pytest-lazy-fixtures and was trying to get the
unittests to run but it seems that I have run into a problem that I'm
not sure on how to fix it in a clean way.

pytest-lazy-fixtures is a pytest plugin and registers itself through the
Python entrypoints mechanism. In its unitests, it assumes that this
registration has already happened but during dh_auto_test there is no
.egg-info directory available. I could use "python3 setup.py develop -x"
to generate it, but this registers the package in /usr inside the build
chroot which I think is not the best solution.

Is there an other, less intrusive way to register the entrypoint before
running the tests?

Thanks,
Michael

[Stefano Rivera]

Hi Michael (2021.10.21_18:55:51_+0000)

> pytest-lazy-fixtures is a pytest plugin and registers itself through the
> Python entrypoints mechanism. In its unitests, it assumes that this
> registration has already happened but during dh_auto_test there is no
> .egg-info directory available. I could use "python3 setup.py develop -x" to
> generate it, but this registers the package in /usr inside the build chroot
> which I think is not the best solution.

I looked at this recently for pytest-doctestplus.

The lazy answer is to run the full test suite in an autopkgtest, not at
build time.

pytest also has a mechanism to register plugins through an environment
variable, but I couldn't figure out how to get the test suite to work
with that.

If you do find a nice mechanism, we should probably apply it to the
packaging of all pytest plugins.

SR

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

[Stuart Prescott]

Hi Michael

I wrestled with something similar some years ago with translate-toolkit, which
has a set of tests that run the binaries it ships but these (entry-points)
binaries are not generated until after installation.

The pybuild/debhelper sequence is to build, test then install; upstream's view
is to build, install then test, and so that is what I faked for that package,
overriding the normal test invocation, and running the tests in an
execute_after_dh_install step:

https://sources.debian.org/src/translate-toolkit/unstable/debian/rules/#L59

I help the test suite find the binaries in debian/translate-toolkit/usr/bin and
pybuild points the test harness at the modules in the normal place in
.pybuild/.

That's pretty ugly, but it has worked out ok for this package.

A related problem is the PEP517 builders go from source to wheel and then
install the wheel; the entry_points and scripts only appear after
installation, and so once again, testing most probably lives after 'install'
not before.

Given that entry_points, plugin registration, PEP517 are all pointing us
towards build/install/test as the paradigm rather than build/test/install, do
we need to look for an additional dh step to be added to our normal sequence
to help us with what is becoming a common task?

regards
Stuart

--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

[Michael Fladischer]

Hi Stefano,

Am 22.10.2021 um 05:44 schrieb Stefano Rivera:
> pytest also has a mechanism to register plugins through an environment
> variable, but I couldn't figure out how to get the test suite to work
> with that.

thanks for this hint, that seems like a clean solution for my case:

PYTEST_PLUGINS="pytest_lazyfixture" python3.9 -m pytest

There is also the "-p" option which shoul early-load plugins by module
name but it didn't work for me. The environment variable did.

Thanks,
Michael

[Thomas Goirand]

Hi Michael,

I do this in many of my packages (or a variation of this) to solve that
problem:

override_dh_install:
python3 setup.py install --install-layout=deb \
--root=$(CURDIR)/debian/tmp

ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
dh_auto_test
endif

dh_install

override_dh_auto_test:
echo "Do nothing..."

I hope this helps,
Cheers,

Thomas Goirand (zigo)

[Dmitry Shachnev]

Hi Michael!

I am a bit late, but nobody in this thread mentioned debian/pybuild.testfiles.

It is a list of files or directories that pybuild will copy to its build
directory before running the tests, and delete after running them.

If you have *.egg-info in the orig tarball, just add that file (and the tests
directory itself) to debian/pybuild.testfiles.

If no, also add this line to debian/rules:

export PYBUILD_BEFORE_TEST={interpreter} setup.py egg_info

Example package where I am doing this is pybtex-docutils.

--
Dmitry Shachnev

[Michael Fladischer]

Hi Dmitry,

Am 30.10.2021 um 22:04 schrieb Dmitry Shachnev:
> I am a bit late, but nobody in this thread mentioned debian/pybuild.testfiles.
>
> It is a list of files or directories that pybuild will copy to its build
> directory before running the tests, and delete after running them.
>
> If you have *.egg-info in the orig tarball, just add that file (and the tests
> directory itself) to debian/pybuild.testfiles.

thanks, I wasn't aware of this, I'll use it instead of
PYBUILD_(BEFORE|AFTER)_TEST to copy test assets into place.

> If no, also add this line to debian/rules:
>
> export PYBUILD_BEFORE_TEST={interpreter} setup.py egg_info

That seems like the best/most elegant solution to me. Thanks for
sharing! So d/pybuild.testfiles is taken into account after
PYBUILD_BEFORE_TEST?

Regards,
Michael

[Dmitry Shachnev]

On Sun, Oct 31, 2021 at 02:40:41PM +0100, Michael Fladischer wrote:
> > If no, also add this line to debian/rules:
> >
> > export PYBUILD_BEFORE_TEST={interpreter} setup.py egg_info
>
> That seems like the best/most elegant solution to me. Thanks for sharing! So
> d/pybuild.testfiles is taken into account after PYBUILD_BEFORE_TEST?

Yes, before.

--
Dmitry Shachnev