search

UnkindPartition / tasty

Modern and extensible testing framework for Haskell
638 stars 108 forks source link

Make ansi-terminal an optional dependency? #361

Closed Bodigrim closed 1 year ago

Bodigrim commented 1 year ago

On Windows filepath struggles to use tasty for its test suite because of a circular dependency through tasty -> ansi-terminal -> Win32 -> filepath. Instead filepath rolls out a small testing framework of its own: https://github.com/haskell/filepath/blob/7139cd3383a2aae440a57b5604a8182d9a983715/tests/TestUtil.hs

If we could make ansi-terminal an optional dependency, filepath would be able to use vanilla tasty to organise its test suite. More generally, I find it very important to keep tasty as slim and robust as possible, because a) it is used a lot to test GHC boot libraries, where no other packages can be taken for granted, b) thousands of CI jobs build tasty daily, so even small savings in dependency graph are worthwhile.

On the surface it seems entirely doable: while tasty uses ansi-terminal to add some colour to the output, this is just bells-and-whistles. E. g., if you run cabal test without --test-show-details=direct, ANSI features are completely ignored, and they are certainly irrelevant for CI runs.

However, a closer look reveals that Test.Tasty.Providers.ConsoleFormat re-exports entities from System.Console.ANSI.Types. Thus, making ansi-terminal an optional dependency would affect API, which is not quite acceptable.

It would be better if System.Console.ANSI.Types was provided from a separate ultralightweight package, say, ansi-terminal-types, which both tasty and ansi-terminal could depend upon. This way tasty could either make ansi-terminal an optional dependency or even reimplement few functions we use and eliminate this dependency unconditionally.

@andreasabel how does it sound? If you are on board with this plan, I can discuss it with ansi-terminal maintainers.

andreasabel commented 1 year ago

It would be better if System.Console.ANSI.Types was provided from a separate ultralightweight package, say, ansi-terminal-types, which both tasty and ansi-terminal could depend upon.

This sounds like a good plan!

Bodigrim commented 1 year ago

This did not work out: tasty depends on ansi-terminal not only directly, but also via optparse-applicative and ansi-wl-pprint.

andreasabel commented 1 year ago

@Bodigrim wrote:

not only directly, but also via

cabal-plan can give you the whole dependency tree.