Support for testing libraries

[sol]

This is more of a PSA than an actual issue.

@augustss I think a while back, somewhere, I read a comment by you along the lines of "testing libraries are not yet supported" and "the majority of maintainers are somewhere between disinterested and hostile".

1. For Hspec support, nanospec provides a lightweight implementation of a subset of Hspec's API. If a test suite only relies on things that are provided by nanospec then nanospec can be used as a drop-in replacement for hspec. Maybe as a stopgap measure, you could special case hspec -> nanospec in mcabal.
2. I'm very happy to accept changes for hspec and nanospec that aid MicroHs.
3. I'm also happy to accept changes to nanospec that make it more compatible with hspec (as long as (a) things stay lightweight, and (b) everything is kept in a single source file).

As a maintainer I'm definitely not hostile towards MicroHs, and I'm very happy to see more choices in the Haskell ecosystem. I would also love to contribute at some point, but I'm busy for the foreseeable future.

[augustss]

Happily, nanospec builds without modification (except that I had to add the 'exposed' field to the mcabal parser).

But hspec relies of packages that do not yet build.

[sol]

except that I had to add the 'exposed' field to the mcabal parser

Ah, that's an artifact from the past (pre-sandbox cabal), so that when you had both hspec and nanospec in your global package database, ghci would default to hspec.

[sol]

But hspec relies of packages that do not yet build.

Some of the dependencies could be made optional.

Is the list of packages that currently build available somewhere?

[augustss]

I just make this spreadsheet

[augustss]

hspec-core depends on tf-random which depends on primitives which is very ghc specific.

[sol]

hspec-core depends on tf-random which depends on primitives which is very ghc specific.

I think this was necessary for older versions of QuickCheck. It's either unused now, or needed for backwards compat code only. I'm on it.

[sol]

Fixed in hspec-core-2.11.15.

[sol]

Hspec also uses type families by the way. We either gonna need to CPP them out or create a hspec-core-mhs overlay.

(The functionality that is lost by removing type families is commonly only used by test suites that test web applications or deal with database connections, so I think no big deal.)

[augustss]

Next problem: hspec-core uses its own version of Control.Concurrent.Async which does not compile with mhs.
The async package has been ported to MicroHs. Can you use that instead?

[sol]

I created a branch add-support-for-mhs (hspec/hspec#932).

We can use a sledgehammer approach, just to see what it takes (including removing type families etc.). Once MicroHs is happy we can see how to integrate things.

I'm gonna send you an invite, so so that you have the option to push to that branch if you feel like it.

[sol]

Regarding pattern, have you considered making it a contextual keyword, only treating it as a keyword if it appears as the first token of a top-level declaration?

[augustss]

I could make pattern contextual. But given that this is the first time I've run into this problem I think it's easier to just change the source code.

[augustss]

With the bug fixes I just pushed to MicroHs it can now compile hspec-core until it runs into a type family.
The fixes are in my fork. I'll move them to your branch when I have time.

[sol]

I took your commit and rebased some of my own changes on top of it.

I force pushed, so please be prepared for that.

Let me try if I can strip out type families really quick.

[sol]

It's stuck at "cannot derive Functor / Foldable" now.

https://github.com/hspec/hspec/actions/runs/20031744797/job/57442398011