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. ;)


Reply via email to