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.
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?
If I add @builddep@, I can miss a 'missing' dependency.
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 ?
This sounds like a job for a custom autopkgtest, not for one that runs build-time tests.
pybuild-autopkgtest(1) has an example of this.
sorry for the noise
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?
Yes, when I generate a python package, dh-python3 generate the python dependencies.
I want to check during the autopkgtest that the runtime dependencies are well defines in the package.
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.
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 want to run the same test suite (which is most often provided bythen drop this variable and list all the packages that are needed to get
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-<package> dependencies and the
specific tests dependencies is a working subset of @builddep@ for
these tests.
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.
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-<package> dependencies and the specific tests dependencies is a working subset of @builddep@ for these tests.
Am I clear ?
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 ?
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.
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 ?
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.
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?
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.
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.
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.
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.
Runtime sure, and we already use that.
Do you have a pointer to this logic,
but usualy we do not tag with <!nocheck> 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 ?)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 158:39:13 |
| Calls: | 9,700 |
| Files: | 13,732 |
| Messages: | 6,179,652 |