Circular dependency with Twisted about incremental HOT 2 CLOSED

The circular dependency is only for running tests, so I don't think this should present an issue for packaging?

from incremental.

Well, python Debian packages these days run unit tests by default at build time. So this means there's a circular dependency at Build-Depends level (iow to build the incremental Debian package you need the twisted Debian package and the other way round).

From a quick look it seems that the tests import just generic twisted utilities like twisted.python.filepath or use twisted.trial.unittest.TestCase.mktemp, both of which are arguably non specific to Twisted and could be extracted, exactly like incremental itself was extracted. Or simply incremental could just use stdlib constructs directly at the price of some micro duplication, or vendor the relevant code from Twisted (would be very small, I believe).

Really, there's no real conceptual dependency between the tests of the incremental package and twisted-the-async-framework. It's just incidental convenience, because twisted-the-actual-package happens to ship a few universally handy bits, and this bits are so small that pulling in the entire twisted to get them seems odd to me.

from incremental.