Future of tasty-hunit

[Bodigrim]

There are all sorts of feature requests for tasty-hunit: https://github.com/UnkindPartition/tasty/issues?q=is%3Aissue+is%3Aopen+label%3Atasty-hunit

Yet all of them are stalled, because we are undecided whether to carry on with tasty-hunit including a fork of HUnit or making tasty-hunit just a test provider, re-exporting HUnit proper. See https://github.com/UnkindPartition/tasty/issues/327#issuecomment-1109603230 for discussion. Re-exporting HUnit is aesthetically pleasing and less to maintain, but on the other side we'll lose a chance to make any improvements unless upstream implements them.

We also need someone to own tasty-hunit. I, for instance, almost never use it and thus cannot judge which changes are beneficial and which are not.

@andreasabel @VictorCMiraldo @martijnbastiaan and anyone else who reads this, would you like to own tasty-hunit and make decisions about its future?

[sol]

As a general note, vendoring HUnit has already caused friction for users.

Personally, I try to only vendor internal dependencies, that do not leak to the public API of a package. That way users are not confronted with multiple, mutually incompatible, versions of an API. YMMV.

However, there is a difference between vendoring and forking.

When you fork a package, it is common practice to use a different name for that fork, so that I as a user have an easy way to understand what I am getting.

This is a friendly request to follow this common practice.

[VictorCMiraldo]

There is a third option: not re-exporting hunit at all and letting users depend on tasty-hunit and hunit and let cabal figure out a build plan. I tend to agree with @sol above, if we really want to package the basic definitions from hunit, we could rename the package to tasty-unit: a small unit test driver for tasty, but not hunit.

[andreasabel]

I have a handful of uses of tasty-hunit in my project, but I have been satisfied with the status quo, not needing any new features.

[Bodigrim]

Status quo when tasty-hunit is, despite its name, incompatible with HUnit is unpleasing, and it's an unfortunate historical coincidence that we got ourselves into such situation. But to be honest (almost) nobody cares or complains. It's not like QuickCheck where users often depend on a network of packages providing Arbitrary instances and property generators; HUnit / tasty-hunit tests are rather barebone. Breaking thousands of clients by renaming tasty-hunit to tasty-unit is no-go in my books, and same applies to other changes if their only motivation is aesthetical / philosophical.

[VictorCMiraldo]

But to be honest (almost) nobody cares or complains.

True; and to be honest, I also don't really have an issue with it staying the way it is.

Maybe we just leave it as is and make it clear that tasty-hunit and hunit are mostly compatible, but there might be quirks here and there.

[Kleidukos]

I'm a very happy user of tasty-hunit and I don't see myself using HUnit outside of tasty.

[michaelpj]

I also use tasty-hunit and am happy with the status quo. However, it seems to me that part of the question is about future improvements. At the moment, any improvements to tasty-hunit have to go through this repository and its maintainers rather than those of HUnit. In principle it seems helpful to split the load.

[ptvirgo]

Looks like this decision is still kind of open. If someone new wanted to make themselves useful around the tasty-hunit library, what would you suggest?

[Bodigrim]

@ptvirgo sorry for a delay with response. Indeed, no one volunteered to own tasty-hunit, so its development is in hiatus. I'm not sure how to resolve it TBH.

You are most welcome to contribute to other parts of tasty though, #408 and #359 could be good first issues.