Install reqlib'd libraries during CI

Currently tests requiring external libraries are hardly ever run. We likely don't want to run them in every job but we should have at least one job that makes a point of doing so.

Trac metadata

Trac field	Value
Version	8.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Continuous Integration
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import infrastructure labels

Also see some discussionon !291 (merged)

Could we put this logic somewhere in Hadrian? It would be nice to be able to use the same logic locally too. Also, has worked on this started yet (asking to see if maybe I should just go for it)?

@harpocrates, I suppose we could. However, I suspect the only reasonable way to install these dependencies would be via cabal-install and I don't think there is much precedent for using the cabal-install executable from Hadrian.

It seems to me like the simplest possible option would simply be to ship a shell script containing the necessary cabal-install invocation. We could then call this (optionally) from validate and the CI jobs.

added well-typed priorities label

I tried before to add support for a rule in hadrian to install a package using the normal cabal workflow but got blocked by a cabal issue.

https://github.com/haskell/cabal/issues/5807

I pushed my branch here - https://gitlab.haskell.org/ghc/ghc/tree/wip/hadrian-sys-cabal

This also won't work anymore when the new-build option becomes the default.

mentioned in issue #16561 (closed)

added Pnormal label

It would be great to make some progress on this issue. Right now I'm counting 34 reqlib-using tests that may have regressed without anyone noticing.

mentioned in merge request !5426

I think the easiest resolution is, remove support for reqlib. Adding tests which depend on hackage libraries will lead to further issues once these packages stop building due to changes in GHC.

Adding tests which depend on hackage libraries will lead to further issues once these packages stop building due to changes in GHC.

I guess we could rely on head.hackage to provide compatible libraries. This could possibly lead to cyclic dependency issues where a patch to GHC requires changes to head.hackage to pass CI and patches to head.hackage need to wait for the update in GHC…

Converting the reqlib tests to include the necessary library code seems like a lot of work too, but maybe we should try that first.

I guess we could rely on head.hackage to provide compatible libraries. This could possibly lead to cyclic dependency issues where a patch to GHC requires changes to head.hackage to pass CI and patches to head.hackage need to wait for the update in GHC…

Indeed this is why I haven't acted on this. Frankly, I don't think we are missing terribly much by not running these tests in CI. There is nothing stopping us from manually running them during the release process as a final smoke-check.

!5276 (closed) adds yet another reqlib('vector') test for #19474. :/

I personally don't think we would miss much if we don't have !5276 (closed), arguably it would fit better in vector. But someone asked for it so I added it.

I assume this is similar for many of other reqlib tests, but I haven't checked.

What's the status of this issue now that some (all?) of the reqlib tests have been moved to head.hackage (head.hackage@3041b814)?

We can close this issue now I think. If you want to add a test with external dependencies then add it to head.hackage.

mentioned in commit 630274f4

mentioned in merge request !7140 (closed)

closed

mentioned in commit f0b15722

mentioned in commit d6b7b24f

mentioned in commit 2c4f08e2

mentioned in commit 3ed90911