-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split out singletons-base
test suite into its own package
#526
Comments
I don't yet find this plan compelling. Instead, would it be possible just to have two (or more) different sets of golden files, keyed on the GHC version? That seems like it has the same amount of duplication as your plan (still need to maintain multiple golden files), but less user-facing complexity. This might be different if simplifying |
My main motivator is making it easier to support multiple versions of GHC as is reasonable. I disagree that maintaining multiple sets of golden files would involve the same amount of duplication. In fact, it would involve substantially more duplication, since now we have to double the amount of files we keep track of in version control. (There are a lot of golden files.) I'm not excited about that prospect. |
Ah -- I think I had missed the point that the testsuite would cover only some GHC versions, so there would be no duplication. But then I think we can achieve that goal without a separate package: just conditionally have the testsuite fail on the wrong GHC version. (Or maybe succeed vacuously?) In any case, it worries me a bit that this plan would mean that we advertise that |
Ah, I hadn't considered that. Indeed, making the test suite conditional sounds like substantially less work, so I like that idea better.
I think "completely untested" is a bit of an exaggeration. After all, most of the interesting work that Relatedly, I've never been happy with making all of the test suites be golden tests, as it's coupled far too tightly with the output of GHC's |
I agree about making the tests more well targeted. And I also agree about "completely untested"..... but the testsuite does exist for a reason. Maybe the |
To make this a bit more concrete, 47 out of the 122 tests in the
So maintaining two sets of golden files (one set for 9.2 and another for 9.4) wouldn't quite double the amount of files, but it would involve enough duplication to where I wouldn't be excited to maintain it.
The |
In #531, I've decided to keep the status quo and require |
Note that the custom |
Before I explain why I want to do this, let me first make some observations about
singletons-base
's minimum GHC requirements.Historically speaking,
singletons-base
has always been tied to a particular GHC version, as its implementation almost always requires the latest version of GHC to build. Or, at the very least, to build without needing heavy amounts of CPP. While this has been true of everysingletons
release that I can recall, GHC 9.4 is, remarkably, not that different from 9.2 in terms of its impact onsingletons-base
. In fact, one can compile the current state of themaster
branch with both 9.2 and 9.4, requiring no other changes than some minor changes to version bounds.This is pretty remarkable, and I think it would be worth considering making the next release of
singletons-base
build with both GHC 9.2 and 9.4, given how straightforward it would be to do so. There's only one sticking point with this plan that I am aware of: thesingletons-base
test suite. The output of this test suite is intimately tied to one particular GHC version, and indeed, the output of the test suite changes depending on whether you use 9.2 or 9.4. Granted, it's mostly whitespace and formatting changes (e.g., renderingType
instead ofData.Kind.Type
), but these are changes nonetheless.I think it would be a shame to have the test suite be the sole reason why we can't widen the support window for
singletons-base
a little. In light of this, I propose that we split out thesingletons-base
test suite into its ownsingletons-base-tests
package. The GHC support window forsingletons-base-tests
would be even tighter than it would be forsingletons-base
. We could continue to run the test suite in CI, and we could even uploadsingletons-base-tests
to Hackage so that those who want to run it themselves can continue to do so.Aside from the GHC support window benefits, another benefit to doing this is that
singletons-base
would no longer require a customSetup.hs
script; onlysingletons-base-tests
would. CustomSetup.hs
scripts often pose issues for things like cross-compilation, so this seems like a natural way to remove that roadblock.The text was updated successfully, but these errors were encountered: