-
Notifications
You must be signed in to change notification settings - Fork 704
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
testsuite: Introduce Cabal-tests library for common testsuite functions #9454
Conversation
47e73e6
to
f08642c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this module to Cabal initially, after discussing the options with @gbaz . We thought that a separate library is a little bit of an overkill, but I agree that it's a cleaner solution. And certainly more sustainable going forward.
Thanks for putting the effort!
f08642c
to
a8fc603
Compare
This could also be an opportunity to dogfood multiple public libraries in Cabal itself by having a |
I don't see why users of |
Can we have another review please so I can merge this? |
I put a needs-review label in the hope that it'll help to find other reviewers. Maybe we should have done it earlier. |
@mpickering: and you can set the merge label ahead of time as well. It also needs a rebase, because GHA settings have changed and the CI in the PR is not in sync with that. |
a8fc603
to
eddf86f
Compare
I rebased, and now I have to wait (another) two days before this gets merged? |
I hope a rebase does not reset the counter, but a comment does. :) |
I think pretty much everything does (Mergify just uses the GitHub API endpoint called |
@mpickering: shall I manually intervene? |
I noticed that Distribution.Utils.TempTestDir was only used in the testsuite but defined in the Cabal library. Rather than expose this in the public interface of the `Cabal` library, it is cleaner to refactor it into a separate library (`Cabal-tests`) which can be used by any testsuite component. Also, in future it gives a clearer place to put utility functions which need to be shared across the testsuite but not exposed in Cabal. Cabal-tests can also freely add dependencies (such as exceptions) which we might want to avoid adding to the Cabal library. Fixes haskell#9453
I noticed that Distribution.Utils.TempTestDir was only used in the testsuite but defined in the Cabal library. Rather than expose this in the public interface of the
Cabal
library, it is cleaner to refactor it into a separate library (Cabal-tests
) which can be used by any testsuite component.Also, in future it gives a clearer place to put utility functions which need to be shared across the testsuite but not exposed in Cabal. Cabal-tests can also freely add dependencies (such as exceptions) which we might want to avoid adding to the Cabal library.
Fixes #9453