Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #16439 > unrolled thread

Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package

Started byAndrey Rakhmatullin <wrar@debian.org>
First post2024-11-08 08:30 +0100
Last post2024-11-11 22:40 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my  uploaded package Andrey Rakhmatullin <wrar@debian.org> - 2024-11-08 08:30 +0100
    Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded  package Roland Mas <lolando@debian.org> - 2024-11-08 10:20 +0100
      Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my  uploaded package Andrey Rakhmatullin <wrar@debian.org> - 2024-11-08 11:30 +0100
        Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my  uploaded package Antonio Terceiro <terceiro@debian.org> - 2024-11-11 22:40 +0100

#16439 — Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package

FromAndrey Rakhmatullin <wrar@debian.org>
Date2024-11-08 08:30 +0100
SubjectRe: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package
Message-ID<JGrBn-7rfh-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 07, 2024 at 08:34:29PM -0500, Boyuan Yang wrote:
> According to pybuild-autopkgtest(1) [1], it seems that Python packages that
> uses Testsuite: autopkgtest-pkg-build will "run the tests in the same way as
> pybuild ... exception that tests are not run in the build directory". I have
> some confusion on it with my recent uploads.
> 
> When I look at fscacher/0.4.1-1.1 upload [2], the autopkgtest failure for
> this upload is weird. In [3], it looks like the tests are still to be
> executed in the "build" directory. 

There is no package build directory when autopkgtest runs, because
autopkgtest runs in a new separate chroot. That's what the line from the
manpage means.

> Since this package is not built in autopkgtest, pytest cannot find
> anything to test and then directly fails:

It's not directly related to building, it's just because your tests are in
src/fscacher/tests and so they are not copied into the test dir by
default. I don't know what's the preferred best practice for such
packages, I imagine both copying the test manually and running tests
against /usr/lib/python3/dist-packages/fscacher would work, but I don't
think either are possible with autopkgtest-pkg-build, at least if you
don't want to do extra copying not needed for build-time tests in d/rules.
In my package (python-queuelib) that has a similar layout I haven't
switched to autopkgtest-pkg-build.

(I would also expect that if a maintainer adds autopkgtests to a package
they actually run those before uploading)


-- 
WBR, wRAR

[toc] | [next] | [standalone]


#16440 — Re: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package

FromRoland Mas <lolando@debian.org>
Date2024-11-08 10:20 +0100
SubjectRe: Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package
Message-ID<JGtjP-7svs-11@gated-at.bofh.it>
In reply to#16439
Le 08/11/2024 à 08:20, Andrey Rakhmatullin a écrit :
> On Thu, Nov 07, 2024 at 08:34:29PM -0500, Boyuan Yang wrote:
>> According to pybuild-autopkgtest(1) [1], it seems that Python packages that
>> uses Testsuite: autopkgtest-pkg-build will "run the tests in the same way as
>> pybuild ... exception that tests are not run in the build directory". I have
>> some confusion on it with my recent uploads.
>>
>> When I look at fscacher/0.4.1-1.1 upload [2], the autopkgtest failure for
>> this upload is weird. In [3], it looks like the tests are still to be
>> executed in the "build" directory.
> There is no package build directory when autopkgtest runs, because
> autopkgtest runs in a new separate chroot. That's what the line from the
> manpage means.
>
>> Since this package is not built in autopkgtest, pytest cannot find
>> anything to test and then directly fails:
> It's not directly related to building, it's just because your tests are in
> src/fscacher/tests and so they are not copied into the test dir by
> default. I don't know what's the preferred best practice for such
> packages,

You need to list the files required for testing in 
debian/pybuild.testfiles. Then both dh_auto_test and 
autopkgtest-pkg-pybuild do the right thing.

Roland.

[toc] | [prev] | [next] | [standalone]


#16441

FromAndrey Rakhmatullin <wrar@debian.org>
Date2024-11-08 11:30 +0100
Message-ID<JGupz-7tes-7@gated-at.bofh.it>
In reply to#16440

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 08, 2024 at 10:03:18AM +0100, Roland Mas wrote:
> You need to list the files required for testing in debian/pybuild.testfiles.
> Then both dh_auto_test and autopkgtest-pkg-pybuild do the right thing.

This is the thing I didn't want to suggest, because dh_auto_test already
works.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]


#16445

FromAntonio Terceiro <terceiro@debian.org>
Date2024-11-11 22:40 +0100
Message-ID<JHKiB-8gT6-13@gated-at.bofh.it>
In reply to#16441

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 08, 2024 at 03:27:12PM +0500, Andrey Rakhmatullin wrote:
> On Fri, Nov 08, 2024 at 10:03:18AM +0100, Roland Mas wrote:
> > You need to list the files required for testing in debian/pybuild.testfiles.
> > Then both dh_auto_test and autopkgtest-pkg-pybuild do the right thing.
> 
> This is the thing I didn't want to suggest, because dh_auto_test already
> works.

One issue is that the tests assume that the code to be imported is on a
parent directory, and that does not really work when running against the
installed code.

I got it to work by making these changes to the upstream tests:

----------------8<----------------8<----------------8<-----------------
--- fscacher-0.4.1.orig/src/fscacher/tests/test_cache.py
+++ fscacher-0.4.1/src/fscacher/tests/test_cache.py
@@ -8,8 +8,8 @@ import subprocess
 import sys
 import time
 import pytest
-from .. import PersistentCache
-from ..cache import DirFingerprint, FileFingerprint
+from fscacher import PersistentCache
+from fscacher.cache import DirFingerprint, FileFingerprint

 platform_system = platform.system().lower()
 on_windows = platform_system == "windows"
--- fscacher-0.4.1.orig/src/fscacher/tests/test_util.py
+++ fscacher-0.4.1/src/fscacher/tests/test_util.py
@@ -1,5 +1,5 @@
 import pytest
-from ..cache import xor_bytes
+from fscacher.cache import xor_bytes


 @pytest.mark.parametrize(
----------------8<----------------8<----------------8<-----------------

And these changes to the Debian packaging:

----------------8<----------------8<----------------8<-----------------
diff -Nru fscacher-0.4.1/debian/control fscacher-0.4.1/debian/control
--- fscacher-0.4.1/debian/control	2024-11-08 12:47:13.000000000 -0300
+++ fscacher-0.4.1/debian/control	2024-11-11 18:13:06.000000000 -0300
@@ -11,7 +11,7 @@
                python3-pytest-cov,
                python3-pytest-mock,
 Standards-Version: 4.6.2.0
-Testsuite: autopkgtest-pkg-python
+Testsuite: autopkgtest-pkg-pybuild
 Homepage: https://github.com/con/fscacher
 Rules-Requires-Root: no

diff -Nru fscacher-0.4.1/debian/pybuild.testfiles fscacher-0.4.1/debian/pybuild.testfiles
--- fscacher-0.4.1/debian/pybuild.testfiles	1969-12-31 21:00:00.000000000 -0300
+++ fscacher-0.4.1/debian/pybuild.testfiles	2024-11-11 18:14:07.000000000 -0300
@@ -0,0 +1 @@
+src/fscacher/tests
----------------8<----------------8<----------------8<-----------------

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.maint.python


csiph-web