On Fri, Mar 14, 2025 at 12:08:43PM +0100, PICCA Frederic-Emmanuel wrote:
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
On Fri, Mar 14, 2025 at 04:20:18PM +0100, PICCA Frederic-Emmanuel wrote:
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
On Fri, 14 Mar 2025 12:08:43 +0100 (CET)
PICCA Frederic-Emmanuel
wrote:
> If I add @builddep@, I can miss a 'missing' dependency.
I too found that with autopkgtest-pkg-pybuild pulling in all
build-deps it's easy to overlook missing dependencies on binary
packages, because all module dependencies
> 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 t
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 hav
> 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 pro
could be a
similar mechanism for pybuild-autopkgtest.
I was told the autodep8 maintainer accepts patches. :)
signature.asc
Description: PGP signature
> 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 tes
>>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-Pyth
> 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 u
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
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 of
> 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 w
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 bu
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
> 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 bet
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
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
On 2022-07-27 16 h 32, Julian Gilbey wrote:
On Wed, Jul 27, 2022 at 07:45:12PM +0100, Julian Gilbey wrote:
On Wed, Jul 27, 2022 at 10:26:33AM -0400, Louis-Philippe Véronneau wrote:
The way I see it:
1. We should have a Lintian tag for packages not using the new
pybuild-autodep8 autopkgtest. It
On Wed, Jul 27, 2022 at 09:32:19PM +0100, Julian Gilbey wrote:
> [...]
> >
> > I'd be wary about 2.2 and 2.3. I have several packages where I know
> > that an automated test will fail; there are all sorts of weird cases
> > [...]
>
> I'd be wary about adding lintian tags for this, though: with s
On Wed, Jul 27, 2022 at 07:45:12PM +0100, Julian Gilbey wrote:
> On Wed, Jul 27, 2022 at 10:26:33AM -0400, Louis-Philippe Véronneau wrote:
> > The way I see it:
> >
> > 1. We should have a Lintian tag for packages not using the new
> > pybuild-autodep8 autopkgtest. It would be even better if this
On Wed, Jul 27, 2022 at 10:26:33AM -0400, Louis-Philippe Véronneau wrote:
> The way I see it:
>
> 1. We should have a Lintian tag for packages not using the new
> pybuild-autodep8 autopkgtest. It would be even better if this tag would be a
> pointed hint that identified 'manually' written unit tes
On Wed, 27 Jul 2022 at 09:18:42 +0100, Julian Gilbey wrote:
> There seems to be little point running both pybuild-autopkgtest and a
> manually written debian/tests/* test suite.
I think it can make sense to have both. d/tests is the right place for
an integration test that checks things lik
On 2022-07-27 04 h 18, Julian Gilbey wrote:
There seems to be little point running both pybuild-autopkgtest and a
manually written debian/tests/* test suite. So would the script only
add pybuild-autopkgtest to packages which don't have a manually
written debian/tests/* suite?
The way
On Tue, Jul 26, 2022 at 11:50:19AM -0300, Antonio Terceiro wrote:
> I think the notes did not capture the consensus correctly. The point was
> that it should be possible to automate updating the `Testsuite:` field
> to run tests with pybuild-autopkgtest, and that we should probably
ntian+Janitor is probably the best tool combo for this, yes.
If Jelmer agrees to do the Janitor part, I'll be happy to do the Lintian
part once the pybuild-autopkgtest MR has been merged and we've confirmed
this feature is ready for large-scale deployment.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Lou
On Tue, 2022-07-26 at 17:53 -0300, Antonio Terceiro wrote:
> Well the idea is to only actually commit the change and upload the
> package with the new Testsuite value after ensuring that actually works,
> i.e. that the autopkgtest passes.
This sounds like something for lintian and the Janitor. I
kg-pybuild
> >>
> >> to debian/control (see the autodep8 MR at
> >> https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs -
> >> it will never automatically detect a pybuild package).
> >> And a maintainer would presumably only add that i
uild package).
>> And a maintainer would presumably only add that if they are also
>> removing their existing debian/tests/control (or want to run the
>> pybuild tests in addition).
>>
>> An alternative would be for the autodep8 patch to try to determine
>> whet
> pybuild tests in addition).
>
> An alternative would be for the autodep8 patch to try to determine
> whether to run pybuild-autopkgtest. One approach could be:
>
> if the package would run autopkgtest-pkg-python:
> if debian/control does not contain an override_dh_auto_test s
ntainer would presumably only add that if they are also
removing their existing debian/tests/control (or want to run the
pybuild tests in addition).
An alternative would be for the autodep8 patch to try to determine
whether to run pybuild-autopkgtest. One approach could be:
if the package would ru
Control: reassign -1 dh-python
Control: retitle -1 dh-python: add pybuild-autopkgtest, a test runner
Control: severity -1 wishlist
Control: tag -1 + patch
Control: forwarded -1
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
On Mon, Dec 20, 2021 at 04:03:17PM -0300
32 matches
Mail list logo
