Re: pybuild autopkgtest
>>I was spoken about the test specific dependencies. >> >>not the dependencies of the packages (dependencies which are imported in the >>upstream module code). > > Well, "the runtime dependencies" means the latter. agreed > >>> Most of them are, considering that the build process of a pure-Python >>> package is moving files around, building docs and running tests. >>> Which ones aren't? sphinx and friends? >> >>So how do we guaranty that the listed dependencies (from the upstream, >>supposing there are right ;) are well define in the binary package >>dependencies >>? > > You again contradict yourself. > Sorry. Sorry english is not my mother tong so I do not understand everythings. Fred
Re: pybuild autopkgtest
> Runtime sure, and we already use that. Do you have a pointer to this logic, It would be great to be able to update the B-D via this mecanisme like we do with cabal-debian. We should have a pip-debian which could take care of upgrading the B-D in the control file each time we integrate a new upstream version. > Test no, they aren't even specified > in an uniform way in the upstream code (it could be e.g. a > tests/requirements.txt, one or several lists of deps in tox.ini or a > custom pip install line in the CI job definition, or nothing at all if > they run tests only locally and manually). This is a pity..., it will defeat automatic packaging... > That makes sense. Or maybe it should get only the B-D annotated with > !nocheck if those exist. this is something I was wondering also. but usualy we do not tag with the runtime dependecies in the B-D field. Do we need to have the run-time in the B-D in order to build the package (without running the test ?) FRed
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 03:24:09PM +0100, PICCA Frederic-Emmanuel wrote: Using @builddep@ is mostly not useful for testing Python packages. does the python tools provide a way to get the runtime dependencies or the test dependencies of a package ? Runtime sure, and we already use that. Test no, they aren't even specified in an uniform way in the upstream code (it could be e.g. a tests/requirements.txt, one or several lists of deps in tox.ini or a custom pip install line in the CI job definition, or nothing at all if they run tests only locally and manually). But I am wondering if the best would not be to have something more declarative like the extra_dependencies in order to supersede the full dependencies instead of just adding more dependencies. That makes sense. Or maybe it should get only the B-D annotated with !nocheck if those exist. -- WBR, wRAR signature.asc Description: PGP signature
pybuild autopkgtest
Hello, Is it possible instead of using pybuild-plugin-autopkgtest during the build, to call the same logic from d/t/control. something like Test-Command: pybuild-autopkgtest-run This way it would be possible to deal with the Dependencies on our own and avoid the problem of missing dependencies due to these @builddep@, variables. Cheers Frederic
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 11:53:09AM +0100, picca wrote: Is it possible instead of using pybuild-plugin-autopkgtest during the build, to call the same logic from d/t/control. something like Test-Command: pybuild-autopkgtest-run pybuild-autopkgtest(1) has an example of this. This way it would be possible to deal with the Dependencies on our own and avoid the problem of missing dependencies due to these @builddep@, variables. Do you mean you don't want it to use @builddeps@ or what is the problem you are thinking about? -- WBR, wRAR signature.asc Description: PGP signature
Re: pybuild autopkgtest
> This sounds like a job for a custom autopkgtest, not for one that runs > build-time tests. In that case what is the purpose of pybuild-autopkgtest ? We are already running test almost automatically via pybuild during the build ? it seems that it was written to avoid code duplication between d/rules and d/t/control. something else ? Fred
Re: pybuild autopkgtest
> You said "I want to check during the autopkgtest that the runtime > dependencies are well defines in the package" and for that you shouldn't > have any additional packages installed, but to run tests you normally need > additional packages, usually quite a lot of them. I was spoken about the test specific dependencies. not the dependencies of the packages (dependencies which are imported in the upstream module code). > Most of them are, considering that the build process of a pure-Python > package is moving files around, building docs and running tests. > Which ones aren't? sphinx and friends? So how do we guaranty that the listed dependencies (from the upstream, supposing there are right ;) are well define in the binary package dependencies ? I just tell this because entry_point checking for the module dependencies. So sometimes I get is missing when running entry points. > Yes, I just don't think the difference between @builddep@ and actual test > deps is big enough to matter for this task and, as I wrote above, this > won't help for your originally stated task so I'll assume you didn't > actually want that. thanks for your time Fred
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 07:58:38PM +0500, Andrey Rakhmatullin wrote:
Yes, I just don't think the difference between @builddep@ and actual
test deps is big enough to matter for this task and, as I wrote above,
this won't help for your originally stated task so I'll assume you
didn't actually want that.
Also, for most packages, the runtime dependencies should be being filled
in automatically based on the package metadata (${python3:Depends}).
Therefore, most of the time, missing runtime dependencies should be a
non-issue, except in the case of dependencies on non-Python packages.
With that said, it *would* be possible to move away from @builddeps@, or
even to filter it somehow. For Ruby packages, for example, autodep8
reads the build dependencies, and removes debhelper and gem2deb from the
list when generating the autopkgtest control file. There could be a
similar mechanism for pybuild-autopkgtest.
I was told the autodep8 maintainer accepts patches. :)
signature.asc
Description: PGP signature
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 12:42:54PM +0100, PICCA Frederic-Emmanuel wrote: This sounds like a job for a custom autopkgtest, not for one that runs build-time tests. In that case what is the purpose of pybuild-autopkgtest ? Making sure the installed code works. But also you should understand that what you want to do is very different from running the test suite, as you explicitly don't want to install deps needed for running it. We are already running test almost automatically via pybuild during the build ? That doesn't check that the installed code also works, and also it only runs when the package is built, not later, e.g. when deps are updated. None of this is specific to Python, both "build-time tests" and "autopkgtests" exist in other packages, and it's also useful to have autopkgtests run build-time tests there. -- WBR, wRAR signature.asc Description: PGP signature
Re: pybuild autopkgtest
> I've dropped using @builddep@ in general within the packages I'm > involved to achieve exactly what Andrey has written, I want to detect > broken or missing dependencies, broken tests by changed dependencies in > other depending packages. And don't want to get this hidden by packages > that are within @builddep@ that potential pull in the other then needed > packages. exactly > Using @builddep@ is mostly not useful for testing Python packages. does the python tools provide a way to get the runtime dependencies or the test dependencies of a package ? This would allow to automatize a lot'of our packaging job, upgrade etc.. > So yes, need to figure out which packages then you want to have listed > in d/t/control to make the tests pass. yes. I will use the doc snipset and customize it to have the right dependencies. But I am wondering if the best would not be to have something more declarative like the extra_dependencies in order to supersede the full dependencies instead of just adding more dependencies. Fred
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 01:17:24PM +0100, PICCA Frederic-Emmanuel wrote: But also you should understand that what you want to do is very different from running the test suite, as you explicitly don't want to install deps needed for running it. I want to run the same test suite (which is most often provided by the upstream in order to test the package), during the build and as installed. You said "I want to check during the autopkgtest that the runtime dependencies are well defines in the package" and for that you shouldn't have any additional packages installed, but to run tests you normally need additional packages, usually quite a lot of them. but @builddep@ are not the dependency in order to run the test as installed but during the build. Most of them are, considering that the build process of a pure-Python package is moving files around, building docs and running tests. Which ones aren't? sphinx and friends? I need to check that my python- dependencies and the specific tests dependencies is a working subset of @builddep@ for these tests. Am I clear ? Yes, I just don't think the difference between @builddep@ and actual test deps is big enough to matter for this task and, as I wrote above, this won't help for your originally stated task so I'll assume you didn't actually want that. -- WBR, wRAR signature.asc Description: PGP signature
Re: pybuild autopkgtest
Hello Frederic, Am 14.03.25 um 14:17 schrieb PICCA Frederic-Emmanuel: I want to run the same test suite (which is most often provided by the upstream in order to test the package), during the build and as installed. but @builddep@ are not the dependency in order to run the test as installed but during the build. I need to check that my python- dependencies and the specific tests dependencies is a working subset of @builddep@ for these tests. then drop this variable and list all the packages that are needed to get the upstream tests running. I've dropped using @builddep@ in general within the packages I'm involved to achieve exactly what Andrey has written, I want to detect broken or missing dependencies, broken tests by changed dependencies in other depending packages. And don't want to get this hidden by packages that are within @builddep@ that potential pull in the other then needed packages. Using @builddep@ is mostly not useful for testing Python packages. So yes, need to figure out which packages then you want to have listed in d/t/control to make the tests pass. -- Regards Carsten
Re: Request to join Debian Python Team
Hi, Tianyu Chen wrote on 13/03/2025 at 06:13:46+0100: > Ping ;) > > Best Regards, Welcome to the team! -- PEB signature.asc Description: PGP signature
Re: pybuild autopkgtest
> Making sure the installed code works. I expect the same :) > But also you should understand that what you want to do is very different > from running the test suite, as you explicitly don't want to install deps > needed for running it. I want to run the same test suite (which is most often provided by the upstream in order to test the package), during the build and as installed. but @builddep@ are not the dependency in order to run the test as installed but during the build. I need to check that my python- dependencies and the specific tests dependencies is a working subset of @builddep@ for these tests. Am I clear ? > That doesn't check that the installed code also works, and also it only > runs when the package is built, not later, e.g. when deps are updated. > None of this is specific to Python, both "build-time tests" and > "autopkgtests" exist in other packages, and it's also useful to have > autopkgtests run build-time tests there. I agreed that sometime running the same test during the build and as-installed is our best option. Fred
Re: pybuild autopkgtest
On Fri, Mar 14, 2025 at 04:27:28PM +0100, PICCA Frederic-Emmanuel wrote: Runtime sure, and we already use that. Do you have a pointer to this logic, /usr/share/dh-python/dhpython/pydist.py but usualy we do not tag with the runtime dependecies in the B-D field. I do. Do we need to have the run-time in the B-D in order to build the package (without running the test ?) No. -- WBR, wRAR signature.asc Description: PGP signature
