Skip to content

Investigate Haskell rewrite of testsuite driver

Currently, the testsuite driver is written in Python. This is a bit of a liability:

  • Having to program in "not Haskell" might scare away potential contributors here
  • Even developers who are proficient in Python probably prefer working with Haskell
  • Managing Python as a dependency poses an additional burden and complicates deployment, setting up dev environments, CI, etc.; especially on Windows.
  • We miss out on the benefits of type checks and typed programming for a substantial bit of infrastructure
  • We miss out on a nice dog-fooding opportunity

So in order to judge the scope of this task, and define it better, it would be good to investigate a bit:

  • What would it take to get high-level feature parity with the current solution?
  • Does the Haskell ecosystem cover the concerns that we would like to address with existing libraries? (Process management, for example)
  • Can we come up with a smart and frictionless way of migrating all the existing test cases in a reliable automated fashion?
  • What are risks and unknowns?

#15363 (closed) is the recent case that sparked this - rather than the proposed patch there, which ports existing Haskell code to Python, we would prefer going in the other direction.

#17933 (closed) is another

Trac metadata
Trac field Value
Version 8.4.3
Type Task
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Test Suite
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Edited by Sylvain Henry
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information