-
Notifications
You must be signed in to change notification settings - Fork 698
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
Use package groups #9565
Use package groups #9565
Conversation
I've left all the working commits there for now so the steps can be reviewed but I'm happy to squash these too when ready. |
Do we use "libonly" to mean tests? -- project-cabal/pkgs/tests.config
packages: Cabal-QuickCheck
packages: Cabal-described
packages: Cabal-tests
packages: Cabal-tree-diff
packages: cabal-testsuite |
0930458
to
f9520ff
Compare
That rings a bell, though you haven't linked to a particular place in code. I think it's a flag that causes tests to test only Cabal-the-library or something like that. CI uses it, IIRC, in one of its phases. |
BTW, I think the separate commits help a lot to understand what is going on, so I'd leave them be. I hope all the project files are actually used and not dead code themselves... |
@Mikolaj I saw "libonly" in the names of two projects:
The packages in each look to be for testing: -- project-cabal/pkgs/tests.config
packages:
Cabal-QuickCheck
, Cabal-described
, Cabal-tests
, Cabal-tree-diff
, cabal-testsuite |
Oh, right, and the project files only contain packages relevant to Cabal-the-library, so it figures. |
I'm afraid many of them are dead wood. Most used are cabal.project and cabal.project.validate — locally and in CI respectively. The rest should be grepped and if nothing comes out could be removed imo. One exception is cabal.project.release, which should be checked against the wiki page on making a release (if not mentioned there, could be removed I think). |
I used cabal.project.release to produce FreeBSD bindists for the 3.10.2 series. I hope it was the correct choice. :') |
Good! Then this is the third one we know is in use. The rest is still under a big question mark. |
Right, some may be used by github CI and others by gitlab CI (the gitlab CI config is in our repo, too). |
The only project not referenced is
|
Thank you for the analysis. I expected them to show up in the Makefile. The issue is: I don’t think the Makefile itself is widely used. Just look at all the Dockerfile stuff in the Makefile — it’s horrible. It would be nice to clean up the Makefile too. Let’s look closer at your results:
More radically, I propose to cut all the project files and Makefile targets that
Putting it positively, we need to make sure that CI uses the Makefile as much as possible, but everything that is not used in CI should be assumed to bit rot and removed. I think there are rare exceptions from this rule that sometimes come from @andreasabel who afair use some non-CI targets in the Makefile. Maybe from @Kleidukos too. |
Yeah I use the makefile for styling. |
Oh, right, the
|
I tried
The |
3fd2032
to
1689491
Compare
I've updated the Makefile recipe for
Note Changing the reference to |
d8f4ee4
to
25d1cf0
Compare
4f9ccbb
to
a63f0ee
Compare
a63f0ee
to
a23a294
Compare
@mergify dequeue |
☑️ The pull request is not queued |
@mergify queue |
🛑 The pull request has been merged manuallyThe pull request has been merged manually at 7e085fa |
I think mergify lost track of the |
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.
Testing.
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.
Testing 2.
@philderbeast: could you kindly rebase manually and then manually merge with no-fast-forward (e.g., via the "merge pull request" button)? Thank you! |
- Move constraints to project-cabal/constraints.config - Remove duplicate package groups - Groups coverage, doctest and validate are the same as the default group - Remove duplicate validate-libonly package group - Both validate and validate-libonly are the same - Move Cabal & Cabal-syntax to pkgs/cabal.config - Add install package group - Add benchmarks package group - Add tests package group - Both default and libonly groups were the same set of packages that I renamed to tests - Put install group before tests and benchmarks - Don't repeat packages - Add TODO and REVIEW comments on allow-newer exceptions - Move latest.ghc configuration - Put program-options first & separate imports - Remove optional-packages - Don't reiterate default value for tests and benchmarks - Don't reiterate default value for optimization - Add ghc-options.config - Rename to ghc-latest.config - Use -Werror in ghc-options.config - Don't include ghc-options.config for doctest project - Add project-config/pkgs.config - Add project-config/pkgs.config importing all package groups - Move Cabal-described to the cabal package group - Remove cabal.project.buildinfo - Have cabal.project.doctest import cabal.project - Split integration tests into their own package group. - Add back trailing newlines at EOF in projects - Integration-tests.config needed for libonly - Add a README for projects.
- Satisfy -Wmissing-signatures in test-runtime-deps - Satisfy -Wx-partial in HackageBenchmark - Satisfy -Wunused-imports in QuickCheck.Instances.Cabal - Use partial pattern for filtering in list comprehension - Don't error on deprecated import
- Reduce duplication in test flag setup - Avoid "New config" picking cabal's own project Before this change, this was the test failure: Unit Tests UnitTests.Distribution.Client.Configure Configure tests New config: FAIL Exception: project-cabal/pkgs/cabal.config: withBinaryFile: does not exist (No such file or directory) Use -p '/New config/' to rerun this test only. Replacement + new config: OK Old + new config: OK Old + new config, no appending: OK Old + new config, backup check: OK Local program options: OK 1 out of 6 tests failed (0.02s)
* Remove cabal.project.libonly It was only referenced once in a stale Makefile comment about doctests. * Remove weeder - remove weeder's configuration - remove its recipe from Makefile - remove its project * Delete cabal.project.doctest - Adding --ghc-options="-Wwarn" is sufficient to avoid the numerous <interactive> failures seen otherwise - write-ghc-environment-files has a default of never
920db0c
to
72be26b
Compare
@Mikolaj thanks very much for debugging mergify. I've made the merge. |
Well done! :) |
I validated master locally to be sure after the merge and it is all good (after the 15 min wait).
|
cabal-install 3.10 mis-handles relative cabal.project imports, as added in haskell#9565. As a hack, try using a magic symlink "@" in every tracked directory that links to the top directory, and use it in the import paths. This stands a certain chance of failing on Windows.
@mergify backport 3.12 |
✅ Backports have been created
|
* Import packages from project-cabal/pkgs - Move constraints to project-cabal/constraints.config - Remove duplicate package groups - Groups coverage, doctest and validate are the same as the default group - Remove duplicate validate-libonly package group - Both validate and validate-libonly are the same - Move Cabal & Cabal-syntax to pkgs/cabal.config - Add install package group - Add benchmarks package group - Add tests package group - Both default and libonly groups were the same set of packages that I renamed to tests - Put install group before tests and benchmarks - Don't repeat packages - Add TODO and REVIEW comments on allow-newer exceptions - Move latest.ghc configuration - Put program-options first & separate imports - Remove optional-packages - Don't reiterate default value for tests and benchmarks - Don't reiterate default value for optimization - Add ghc-options.config - Rename to ghc-latest.config - Use -Werror in ghc-options.config - Don't include ghc-options.config for doctest project - Add project-config/pkgs.config - Add project-config/pkgs.config importing all package groups - Move Cabal-described to the cabal package group - Remove cabal.project.buildinfo - Have cabal.project.doctest import cabal.project - Split integration tests into their own package group. - Add back trailing newlines at EOF in projects - Integration-tests.config needed for libonly - Add a README for projects. (cherry picked from commit 0876e18) # Conflicts: # cabal.project.release * Build all local packages with -Werror - Satisfy -Wmissing-signatures in test-runtime-deps - Satisfy -Wx-partial in HackageBenchmark - Satisfy -Wunused-imports in QuickCheck.Instances.Cabal - Use partial pattern for filtering in list comprehension - Don't error on deprecated import (cherry picked from commit 8453ee0) * Add an intercepting cabal-testsuite/cabal.project - Reduce duplication in test flag setup - Avoid "New config" picking cabal's own project Before this change, this was the test failure: Unit Tests UnitTests.Distribution.Client.Configure Configure tests New config: FAIL Exception: project-cabal/pkgs/cabal.config: withBinaryFile: does not exist (No such file or directory) Use -p '/New config/' to rerun this test only. Replacement + new config: OK Old + new config: OK Old + new config, no appending: OK Old + new config, backup check: OK Local program options: OK 1 out of 6 tests failed (0.02s) (cherry picked from commit d336275) * Remove dangling doctest TODO left over from #9572 (cherry picked from commit 619befd) * Remove allow-newer exception for cryptohash-sha256:base (cherry picked from commit ed5d404) * Remove projects; weeder, doctest & libonly * Remove cabal.project.libonly It was only referenced once in a stale Makefile comment about doctests. * Remove weeder - remove weeder's configuration - remove its recipe from Makefile - remove its project * Delete cabal.project.doctest - Adding --ghc-options="-Wwarn" is sufficient to avoid the numerous <interactive> failures seen otherwise - write-ghc-environment-files has a default of never (cherry picked from commit 72be26b) * Update cabal.project.release --------- Co-authored-by: Phil de Joux <philderbeast@gmail.com> Co-authored-by: Hécate <Kleidukos@users.noreply.github.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
We have a lot of projects and they each have packages. Borrowing an idea from Updo, we could group packages and import these groups, fixes #9622. I've also:
meta
project, projects import package groups.release
project now builds with--index-state="hackage.haskell.org HEAD
withghc-9.8.1
(Build cabal-dev-scripts with ghc-9.8.1 #9600 does more in relation to this). A spin off from this work is the CI check ofcabal.project.release
in Add a CI check of cabal.project.release? #9601.ghc-options
, all import the sameghc-options
.ghc-latest
, all import the same config for this.Template Β: This PR does not modify
cabal
behaviour (documentation, tests, refactoring, etc.)Include the following checklist in your PR: