• Re: pybuild autopkgtest

    From Andrey Rakhmatullin@21:1/5 to picca on Fri Mar 14 12:00:02 2025
    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

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfUC60tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh ghEP/jTcTvZ7RwuWPJ8fvGuRJVsm4ExVhbhyvY5VfPs/tmoldLCjTkyyuvZsz0KN YIITyEcKCcrYM6LIgQGnTeWx7TeaLHeMCWkuudWRW0bJd6DLHLu0eWBWhSQn8apw NP3l4NZzfupJLMWIlwJmT7juG9nvCvbZiR8J03YLGjBhRY1k2IH5/6ZksT80T/Fv zeU7AnMCAMbfaMK5+NUegpKx01GeN34Q1YfzaKi6GFXUB4UhV8lvmbFwM0rKrNIR iJ6JiCFgXt2izvRsbkh5khM110hfBKRZaB523s3/DcmM1lQeGSrPHJAFJmm0KDQh DVnHvx/tOgTRwmQEICbd6IRgJ3RhcU2jQ/g6UIrrtSSisrWwImNPl382vVq7DpPO VvSUoJkax6T81K1+biroQxBYft1Mb43gp/8Tmw3l7CUj6Tajo63YdQoPzaqswYFe ixIzYpvEc/DWIhNnvvnqasfiSQX7xpYVrszzVhLVf8LZMhao6HIX2PMXoMFucJN2 /QI+ZzCwzqe7L/R3VIBw9sF7eZGCfHTzisrPkBcbD/UF9TkvP7FE6mMlaATmdZSQ 5CwKIfe/YATqG4z1CFJfezNAaJw8BO1q6dfw1cldZSaysD23YMJiOiHO4XQzR21j /P9iOD7ro/2R7PoM843hXELKt7Hzxd7V9lh5wsLMEj6V3bDk
    =9xZi
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From picca@21:1/5 to All on Fri Mar 14 12:00:02 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 12:30:01 2025
    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.

    So usually, I just depends on the python3-<package> and the test specific dependencie like pytest etc...

    If I add @builddep@, I can miss a 'missing' dependency.


    Fred

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Ploemen@21:1/5 to frederic-emmanuel.picca@synchrotron on Fri Mar 14 12:40:01 2025
    On Fri, 14 Mar 2025 12:08:43 +0100 (CET)
    PICCA Frederic-Emmanuel
    <frederic-emmanuel.picca@synchrotron-soleil.fr> 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 that should appear as deps
    in the binary package are also listed as build-deps to enable the
    upstream testsuite on build.

    A simple workaround would be setting the Testsuite in d/control to
    run both autopkgtest-pkg-python and autopkgtest-pkg-pybuild, which is
    permitted by spec but unfortunately still very much broken (see
    #1042717 and #1061620).

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmfUE6sACgkQQoMEoXSN zHqS7w/+Ng9GZB0nIrxCPIuEFvekwt8VYYYahdRpMa+C7gB304fPid+BW72it/gP aaZkjPCbyPHgcuOsP6cO7SCeTKJ1SU248r50P2llu9CM2rV2MgTtDYpmtmLShfs/ PqtUARlSv1GVa+Pq87LFo7cu++Nn9ebppInUK6qv01Op//N1EV/g/RKCxZOYi7/l h5GluotGYhyKW5FZ4sNNhjImkrQr/dB5uyDSMkIQ+dtRXsyoRiLX8aKq7YdsAml6 3niCcVOlV9rb0c2KnNfA8ur218ZufFy8i3woNrLi/60lhhhZTDLiW953dg7VD2yF jAUKuvvUfKH7+BAjis0VLa0WiZlyrplDGIF6o0IZB0TFZI7y806dpYkhHcEe3Ovb cepp5x8PkpNVs2QjscolJohWVl5/uXdu329kUoQh3vvZvegO7DUJhE4oJ8uv28/H 89sGHfVG6apor1iw8OAsxmsOV1dD3Qh5/cm1mb+vltpBodwr6cwvWSaJRkWvBIP7 IzdKT/4Hm6wJugHknXpSiDm7sSwhLiBlQMHWBSOMOL9h5um4RXR9RwPiixdb9ii3 /pn1B+VGVQO1Q6nesvZDxWTGUfZBJUtpf02map4lqaFBPvz6loBqCGkGS7f1DVq7 79I8piEGAYXg7IUHxT9BCebsW1lvHi3e9ihTqSUD5A+c6dxBCuo=
    =bxvi
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 13:00:01 2025
    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

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfUGFAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh M+QP/2FcLRJ1dETQG6LCbPvuWZZSQWtXSDMqxZy6dSUqHGqMMQB3RQNIHHUkAulg Pr2VwTQGsue2IxJ1BgAdBGGY4+r1fmBKjR3k6oZMYhGgNZHnNt1nD2BCbwUfVlyg brczTLffg/Z9j3A4fvgTw5PjYsfFyiPoti0dPDW8z87U33xt2CEdF+SFzlZRcDlF VtsA/TjD9k3f2faIK+/Xp5dDnjUj5+8glgT3hBGOSIlp8txcaYaLYNEK/HdV1JWu tEdk9DjsbOYxwzJD9u4RCjyvXyODL3tfrV/CHXZMG5GLCGw0Ah0Cjx28mRyQgMXi KcZK+IuYsAmEYtSmo3701j7zC1rr180O6TveAFvYScd8wPyByC7UwSjtCuXhtI9D E9N98X41QQjBCu+gke1h/1ddYbTwoh04OM8c67Q6xO3FchEGhBINSYnT9/fe4cRp eb2UBTzezbW+T6qiuokxHyYDmJEg7KBwDOX/MOybAFdn4/TId7G5K6Hee9SwXsqo VlIyDAsWdOuIhDdr5jWnCR956hxnV2MDtNY4pBOdmaKdV6qhwbnLLLve4tShJpSy BlNFTTR1GtSQKozM5mSLYVYUBC44u+PVmFSw9xvf7Af8dbX8y/nqelnDLO2fxaqq dWngR5GrmKbZW4sWjzBsAs9yX+Dq8eVl52p4k4/OQxmh1BpX
    =YjoM
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 13:10:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 12:40:01 2025
    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.

    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.

    This sounds like a job for a custom autopkgtest, not for one that runs build-time tests.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfUE5ctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh CWQP/Rx4kkDgNPcG6qyP2jvUkmNFaCZ8kXNGkzDm2igx+G8YUcOb6/xezlGcAyiQ v57HFqvUjEgQggTNXm8P8encY8SCyrbqOfnBZvBozCarhWf/pxzrTf2B5K/+IHvY DbP2zqPUYL84QEuIKih3f1q0wb45kjMdburf/UgUT96xZi/Q1/D6OVOaImZSzUr9 gWIddmdpWgjIH+5kSoBDby7CrjW/QK9PwW/HK3k7Cavbaheka3vBQQxKq0Oy/drH HmK1cySjnac3lSlMC5q2pmV/EgyURWncNqc8pboPLPBizle0ed8/yIw8ab/TlikL j0cRydFpFDOYsL3yyZO4EgTqEdMT9+NVQpTHh9YSDx5Mb6I8VTqX2PGs6XBt3luK f5WZyRHavSG5RzwryMnc+sOvZbIzSe1h/Cjjh5fLhyz21Jy9bS0AWk/918fJVxCf DuOig+gIN4kX8aiueG6rXmR2TBw9Biit8tOLR6/WZEXRWqSrLAex/0SRW78IS2F7 p6hutSBnOn7hDzjoQr7BZmBs2N7OFraRicGBWFZ5A/Sj2CGK6/TjGM6sNSryNPYx KMmv0nq9zMrUclUPitzIoI2A9wxz7QI8BA20OU39dkEGcNEyVgamWvoJgKJPvGes AY0nX7lO76XRQruyHUai/D9SMy0+AH7aPTqH1qBM+HBZSuqk
    =0o4g
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 13:40:01 2025
    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-<package> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carsten Schoenert@21:1/5 to All on Fri Mar 14 15:10:02 2025
    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-<package> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 15:50:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 16:00:02 2025
    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-<package> 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

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfURB4tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh oMgQAIOoC+5khuo5AqDbSm5foffQghBUJuo2vUojB+c+cBw3c3WLzblCxgJ4BYfp dfhjDzPRgt0nt9Qn2ZIzyZ+8jz0AQwrMiNKZewT6J7fTbmTQVG1m6iqhiFkUoN5t dyIiWs4OEbhyPdZVNw73qt+w5oCKrkn8szrwalD/DCdZKbpbk2gzhrEcxIEi6zmk uNl0QrUq3F+4YoK6nmep1HV5QpeaDfpAS05QTf+0E27plZzhcYBp4P34Dc27ku4M hZt2CWyeohzmQ3jU9biTOPa72jQqb0w+BD8Aj4M4Suuu3FRuixYPdlv+J21FKPk9 szdMJc7pW0atRX8PXyWceMYSXc5Pzvr7nf7gNYaDqih5RhYYE6w+g//aayqEo62Y v/oGdXHu9nipeATf3Pw0gQMaDAZYZBipxvNBed0qZNDkS5l5yhefWZv07PE6M2G7 a5+2hk9x2gqzrsju98XPzITYNchTvjkfp1nah8J7gBHWjpVHVyDAUCWUlvlAzTp0 ncaBf8ch8cY9TubcCcS5tH3CEXwrv3bLyYMmu9KrCA8WIFb/xS0RD7WBib6SDGq6 IjkIyp9aaxviroubipaJBHDHWNYoVUA/zse70Mn5qtKUQQgBfGVaPGdK6lyfkJos xP5rX5lBa3FMPXkyR3GsXxtpr/xMg1iTxDOJygCMYHzjwlDa
    =JBDx
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 16:20:01 2025
    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

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfURtktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh AUEP/1ml6jqEflgPP9OsfW/RGOolFy0QuI/FGoRsu6x7t/wEDhfQhfZ7cCV7//Kq ld47I6tWG4PhHcObiRmRiKNKE9FLbtK4+U2Zlr+MVqOwpydiCbr3Odff0Jy+4mVb VuY3HAvC/A2v2xBkSrboY06jz1CcqZbY1unyqzV8pww9xTCvBcrgmErjrL6QbCMJ vMcLJUijrNH2OR9w8jZL7KYaE//y8DogiCYKX1qzmhWzIkp+xur750jtJAvumQ/V p/oexNd9l/jPDl9CnGYZsPAQxK0JT+gm/EpFX7bNzzCmeWxC55ta8rSKiESF3Vf2 0hE/M+oUz6eYOC3TelO2UzuboYqumYSWoFsM7xT8v0gadclb/MnFEJs1RDQYGF0H fMMYxAjim3T8FDTcF9PRg6DsmcPP9rsdoNVlyuQ1RHlw4HgkFoBUarFYz0M2K56p XN8LTcUE8+Irzr9aGN5+g23CQ0YCYcxZNOGfR78ilu8TDFdWjaoS6XrGjI/o26ec o1UQ7YJBn8SpSTEFnkJv+Ts6j6k0cFZlecVEtip+j3X0sfHvOf+L64koOdbdnixU BlJF3zZwZrIIgtSbWcLvfkNhJdDVJc8nS9+QCEyTJvIOpD3AGjVTKP5N4UEXkiN0 u1qcRFHlI0lMLM17iEv6fOTE3gMW9OuoJdeZRSLX99QwDNV6
    =CGzq
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 16:30:01 2025
    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 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).

    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.


    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJgBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfUSoAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 244P93LjaPRpraxq6dxFNSujeUby0L3LCZV20ZzrjBHQA4SjVuAHwfbNZF3X4myB aFXvvhfsEtPDx/OlU5stV/kDve8gynjjOfwC7+79QVYSADrWmPfm2WEPG/Ir78b1 aYjXl0SGxfQWYfAWKruKTPdfQutQgruvOnPvgFbSBxXMReMVp47fKtUWUyeXnrip 4Wtfhv3CMYZiaDHZj9lW0H6pqs6omV/RA/rDl6/cCYyptrQcFp0MXdxcLmlItl4d PPYifGlf4LzDE7n49W0d0qlWkU8EYp/nAroRJjAlaGz7vqDTrd5OaZckP5ICF/70 auHSj0id3oyv28HWq/K3z0oGyMwJnC+lSrSWsdpqVKsLBKPgFRWtXDiXp2efzRQR mxe+gY+5F6YAnueb+vhOwEwYkysaq0fLhb5oRyyWz9FJSVhKr9rmacGpkUhodg1Z 87Tk4ZH/Sjcq/vXbkf5ELrYzIazZfqH8qzNOD1ENfL0Cjyce2PS+E9SlTx6U/yA4 fjHr6uqRhBozhA+TISGIghskLqPUQ81BcMt1YyBWoSPPio0z9Qj0+V4jLl9RksCa w18VydLnirSRxLrZDphOt2tKVvMxDXZWzGp6dLm1IaChg+TZ9Kkp3fcEasWg906n lGB0x/lYt+vaF78sJJfd90+u/IeiDpWwkr8UUAVno3ttaOo=
    =EMQs
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 16:40:01 2025
    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 <something> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PICCA Frederic-Emmanuel@21:1/5 to All on Fri Mar 14 16:50:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Antonio Terceiro@21:1/5 to Andrey Rakhmatullin on Fri Mar 14 17:00:01 2025
    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. :)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmfUUS4ACgkQ/A2xu81G C97MnBAA2nVmUIYVDrD0pAgyY2t0BXI1BPESIdY/1jyhjzMokKMwamTr6m/X7QsG h94W8HmWNQBMc+SA8jQmr6yTRQOh2Ba55rd/lu/1OH1D2rl9plSKFYUKo4qO+z60 UjwT8cNUAVrGb9EWcCFSQkDwINxyh5e3O4bn4WnKwbY8yyq3VHxGUC2bI6GhdnBg OSUoMKbnXPKn0eFs95ceE/Lr1x2nUD26SJbalIrQhVRaaUi2co/qBeQuTKEBwrjN 4ehm9OT6uYc7u/VWncv1n96895Wr8lUoRh2lw1jYlKyVFmMuP63CayfqNaBDdqZS +x/vejsMM2ZM3qskrAfYPSLPIx4nrEeOhdZyR6Dg/sw+KGvHITLEpn8os3Jbm2Kx dxjC7kq4E3I+ahfhtOSXrvAY37ACk3nDXdGzjMlRF8lN/Vfq1HPY3BlustC6ovcN 8uV5eyo4Ehu6qpU8AZQYwmr99u+vO2ICwHlMC4l0MeHpaOn9donm0MR3Oyv5qysa +djpZjR0sb0nZbfwyYWcg8tU0HmyIiEjcds3v4ZoJLXnA6BhjxH1KxdA2ocvOyOM oQ8IC6j9rifwHJ37zwg0ZvKPdNU351uem7K0lUcEQEva3JwqGILDGHtiZx0HAgov 060epSNu9ASBmCUzMWy5bEEFgnqQi1nOcRizsWcv4950FRQqi/M=
    =Hk1L
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to PICCA Frederic-Emmanuel on Fri Mar 14 17:20:01 2025
    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 <!nocheck> 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

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmfUVZUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh Mj4P/2c768tc88WLuy7v+BtqbpnAae6yCx/1mIY/9zogGeiXzuU3Q3Vwq3K6dHRp q9/TbSkvMbv9st7B7RSJdyVVpen9W1xqvGP7IaaFYllaj0aBzkRLKjWeSmAkiDAN qdZVpHMNDFrZejWWZ1QVvcl6+Fj55mUVWscYvCdQebss+28NgL+Ceyr90e6Vu3I6 V1UXFSTISQycdRCDpAyP7gu1rp1KM/MIYxCrRMny8jFTPhlpIHcueX7KneRZEUZ5 J4Qtz5SeM51lGcwCWtyV6wleWo3Z1ySFrnMDBleGLz8f9U4Y2iRBSDl2axW+Psz9 NKB3qMsuMbRACHDs6BdVSBjD7J8cuZotkEGnVpErVeG7FKkyL6IRZ8s5KrOi5BbG HKqEliCfJGGxKDmEcUQVG8jjbc5vxUrzO1o9DQpLM4UxM8Y/tJSPyTsxlaKZaP4f xjxfWUZ/HVr9/fh7JvO714OmfjxeqiMzN0rOCoRnoT+OVttELVdc0d5BNJ5xVVc3 bH7QbdyjbcBXYGUfc3+CV7vcwDqKDVpxRBat0Oy9dmBL1j8gRBPhJbUeh0Fy3XEf PtWwKYuSK92GVQ+6tklWKT8GkIdnAmnvfG3Yy5zuRUIRGRMRFnDFgJoge7CextqX E8lGKyfnfvwq4SpSUdREPDcXbLHcmkTt+EmMjyxwf0IMAnFh
    =UcVu
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)