Hello,

I'm upstream maintainer (but not founder) of "backintime".

I realized that most of the tests in my test suite are integration or
system tests which are impossible to handle by Debians build server and
testing system (how do you name it?).
My package do use something like "./configure && make && make test &&
sudo make install" to test and build. Works fine on a local Debian box.

I would like to have an advice from you as DPT how I should separate my
tests into the two categories "run by debian" and "don't run by debian".

One approach in my mind is to add one new make target "make unittests" containing real unittests able to run on Debians build system in a
chroot.

Another approach in my mind is asking for environment variables that
might exists on a Debian build box? I know this approach from TravisCI
and ReadTheDocs.

Or any other idea on your site?

Kind
Christian

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

Hello Timo,

thanks for reply.

Am 28.07.2023 14:56 schrieb Timo Röhling:

I had a look at the backintime sources, and I noticed that you

First of all: I haven't nothing. :D I'm not the founder of backintime
(BIT) just the 3rd generation maintainer trying to modernize an over 15
year old python application. ;)

implemented a very unusual (for Python, at least) build system.

Yes, pyproject.toml etc is on my list.

There are also tools for test isolation such as [2].

Tox? How can tox help me here? It is to run multiply python versions,
virtual env and things like this.
Tox, poetry etc would just make a build system more complex then it
need. Currently I see no advantage of it from upstream perspective but
I'm open to new arguments.

increasing your workload by maintaining an extra set of tests
for Debian

No, that is not how it is. It is not an extra set of tests.

In theory you have three kinds of tests: unit-, integration- and
system-tests.
To my knowledge only unittests are making sense to run on a Debian build system using chroot.

BIT's problem is having no real unittests. But if I want to make them accessible to Debians build system excluding the other tests.

It won't be a set of tests realted to Debian. It will just be a set of
real unittests running everywhere.

why not let backintime take advantage of established
practices and tools?

I'm working on it. But breaking the whole project structure without
knowing all details of it (because I'm not the founder) is to risky at
the current time. Maybe when Debian 14 is stable. ;)

Kind
Christian

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

Hi Christian,

* c.buhtz@posteo.jp <c.buhtz@posteo.jp> [2023-07-28 12:14]:

Or any other idea on your site?

I had a look at the backintime sources, and I noticed that you have
implemented a very unusual (for Python, at least) build system.
There are well-known tools and standard practices in the Python
ecosystem for packaging [1], and much of the Python packaging in
Debian is designed to work well with them.

There are also tools for test isolation such as [2]. Instead of
increasing your workload by maintaining an extra set of tests for
Debian, why not let backintime take advantage of established
practices and tools? Not only will this reduce friction with the
Debian packaging, it will generally make your package more
accessible to other Python developers, which in turn may attract
more people to help fix bugs and keep the software in good shape.


Cheers
Timo

[1] https://packaging.python.org/en/latest/tutorials/packaging-projects/
[2] https://tox.wiki/

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

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

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmTDuxQACgkQ+C8H+466 LVlfLgv/VdEY1nFAcNvJcce816jOyBavBhqacmDasWf89m90k4TR9EnY89jpqJG+ 2S2gRza3LA35ji55HKUskONJvIUEpK0USbFqGcBfxwfT3jyLHINCG8xfDKoM83/n yiWF8SdEbyZKw+KsNKArLHtDcX5xluugn1VWO+pheF1o67VfffnO/KSUrv/7ck1r I4rt1x2UswGnwdSkqwN/XVNlkHLLGK9wEacp1HXaaHfIcHwTLRSU9YqEJytqkBOw fvXVW6/ZZlH3QCcwiq59906LQpJRUdqF3bOhgdRyH2KpOzhjoPEw0hQVXjJVCZ7F rLDylQOtGiEw/XibMvkDVN00/NyaVZ3FVb01lJMCOWM

On Fri, Jul 28, 2023 at 12:14:33PM +0000, c.buhtz@posteo.jp wrote:

Hello,

I'm upstream maintainer (but not founder) of "backintime".

I realized that most of the tests in my test suite are integration or system tests which are impossible to handle by Debians build server and testing system (how do you name it?).
My package do use something like "./configure && make && make test && sudo make install" to test and build. Works fine on a local Debian box.

I would like to have an advice from you as DPT how I should separate my
tests into the two categories "run by debian" and "don't run by debian".

In the context of DPT I would use pytest marks.
For poorer test systems it's possible that there is no answer except
splitting the tests into separate things and providing separate commands
for running those.

Another approach in my mind is asking for environment variables that might exists on a Debian build box? I know this approach from TravisCI and ReadTheDocs.

You shouldn't check for Debian-specific envvars in upstream sources.

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

On Fri, 2023-07-28 at 12:14 +0000, Christian Buhtz wrote:

I realized that most of the tests in my test suite are integration or
system tests which are impossible to handle by Debians build server and testing system (how do you name it?).

These sorts of tests are suitable for autopkgtests run on debci:

https://wiki.debian.org/ContinuousIntegration

So you can tag your tests as suitable for build time or not suitable
for build time, and then run build time tests on buildds and others on
the debci service using autopkgtests.

--
bye,
pabs

https://wiki.debian.org/PaulWise

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

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmTEj1YACgkQMRa6Xp/6 aaMjxBAAuQbffYd2Xiyz3gDHECAAPFieSSK5piTNrG4tn2x88zmTXpx/7mwV1Oyz ycd71iN3fk0ZgFUSYLKQsNYfsymzWRI9rXhqQqtF7OxkRS4jRsGT8nEjL9GLUNyR ddSnkYDMyEFtjLJcoUXd/wyOEmUtBxCrxvjBn5YqrsB/QVamFFM0QdmxpmIIHLE1 wpk1LL1GTvOCu7xHeS2/oM2COklsaJWerlDYfTPKj4B6sTnS+E6eNs+iSf6UNR3M FfYiQkp4RRnthYEw9E5V67hDhBvMB3wN+xkvBvF3F5tc9quUJYDf0ZPRm/t5BS3T XZ/6QDlEkR5jqXziakyCv3pGqS1cxMTCyukVs7rISnu+yIrYhNgMxhOsoR79v4T0 2gz0+8SVuwpC8lOjEw2cIjZp4GTn86aYbAagIjBJpVjRDa3qe2TYEx9LoHk+QyxU MY8WsIhaM9Oh+JK+P0uDAPfEa2qyOfeLD8zRTpK8jUaLh7FHZ2dpOYH34qREJZX+ v/nfGncmmuUNt7wRuv2hqqSb0AuKj+8nBTxpcN3X08uUYtdioUW3Tll7qP45F3KL p9Gvwx20kf7zr7W2Oiv5SzXBM/EEE/KBNV/Ws71nyR0YDmfs7vcvtkypbrzAan/j 4WaOUEIPWDLMMrtcBAXa0zDUuFMCnEBQ9W7teCDz37HYEMdERgg=
=6ZAO
-----END PGP SIGNATURE-----

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