Skip to content
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

Consolidate all cabal.project files #2866

Merged
merged 12 commits into from
May 5, 2022
Merged

Consolidate all cabal.project files #2866

merged 12 commits into from
May 5, 2022

Conversation

pepeiborra
Copy link
Collaborator

@pepeiborra pepeiborra commented Apr 29, 2022

Consolidate all the various project files into a single one that aggregates all the allow-newer and constraints from the existing project files.

  • cabal.project
  • cabal-ghc90.project
  • cabal-ghc92.project

This is possible now that our dependencies (stylish-haskell, hlint, etc.) have moved forward to ghc-lib 9.2 and that all the per-ghc-version cabal flags have been eliminated (#2867).

cabal.project Outdated Show resolved Hide resolved
@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch 3 times, most recently from f11c688 to 99f0217 Compare May 1, 2022 20:28
@pepeiborra pepeiborra changed the title Get rid of cabal-ghc90.project Consolidate all cabal.project files May 1, 2022
@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch 2 times, most recently from b22ade9 to d6cdd0c Compare May 1, 2022 21:54
@pepeiborra pepeiborra marked this pull request as ready for review May 2, 2022 06:58
@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch from 439c689 to cf05dee Compare May 2, 2022 10:42
@@ -113,13 +113,6 @@ jobs:
ghc: ${{ matrix.ghc }}
os: ${{ runner.os }}

# repeating builds to workaround segfaults in windows and ghc-8.8.4
- name: Build
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously we could have had plugins which built on GHC X (and hence weren't commented out in the special cabal.project), but whose tests didn't pass (and hence weren't included in the testing workflow. These plugins would have been built by this step, which would have ensured that they kept compiling, even if the tests didn't pass.

Now I think we will only build stuff that's necessary for the tests that we try and run, so if we don't test a plugin we also won't ensure that it keeps building.

Also I think we won't check compilation of the main HLS executable either?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good observation, thanks!

I deleted this step before figuring out that we can use the buildable field to selectively disable projects per ghc version. With that trick, hopefully this step can stay and we can avoid all the pitfalls that you discovered

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a feeling that that won't work. I think I suggested this to @jneira in the past and he convinced me that it wouldn't work. I can't remember why though >:(

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see the reason why it wouldn't work. CI is failing because the Cabal plan it computes is wrong for 9.0.1, but I get the right plan locally so it might be a CI bug

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe it had something to do with Cabal not taking buildable into account when making a plan, so it won't be clever enough to try setting the splice flag to false if the splice plugin isn't buildable, it'll just fail. Worth checking though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't need to be:

if flag(haddockComments) && (impl(ghc < 9.2.1) || flag(ignore-plugins-ghc-bounds))
build-depends: hls-haddock-comments-plugin ^>= 1.0
cpp-options: -DhaddockComments

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so you're going to keep the existing machinery? Maybe the thing that wouldn't work was a more ambitious thing: I'd though that maybe we could automatically have plugins be enabled or disabled depending on whether the plugin package was buildable given the rest of the configuration or not. So then we'd only have to put the logic for deciding buildability in the plugin package, which would be nice.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One step at a time..

@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch from ee5d6d8 to 77cca7b Compare May 3, 2022 15:03
@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch from 152307f to a65466a Compare May 4, 2022 18:50
@pepeiborra pepeiborra requested a review from fendor as a code owner May 4, 2022 18:50
@pepeiborra pepeiborra force-pushed the cabal-ghc90-no-more branch from a65466a to acf3603 Compare May 4, 2022 19:05
@pepeiborra
Copy link
Collaborator Author

@michaelpj the Nix CI is failing, but I am going to leave it to you (after this PR has landed). Deal?

Comment on lines +20 to +23
if impl(ghc >= 9.2)
buildable: False
else
buildable: True
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not ideal, afaict, this spreads disabling plugins over multiple files, but it looks like we have a hard time doing better than this.
Is haskell/cabal#7783 good enough to allow us to centralise this again?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know whether it's good enough, but I agree that buildabilty with ghc x.y would sit better in the project file

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think it's better in the plugin files! "Does this plugin work on GHC X" feels like a concern of the plugin.

Copy link
Collaborator

@fendor fendor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, awesome!

@michaelpj
Copy link
Collaborator

the Nix CI is failing

It's already broken, you're not making it any worse!

-haddockComments
-retrie
-splice
-tactic,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the retrie, splice, and tactics plugins also get buildable conditionals?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, how is the CI passing?? Did they just start working without us noticing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, it's because we still have the GHC conditionals for inclusion in haskell-language-server.cabal

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah you are right - I'm not sure how cabal build decides what to build, so far I'm just adding the buildable conditionals on demand

@pepeiborra pepeiborra enabled auto-merge (squash) May 5, 2022 11:56
@pepeiborra pepeiborra merged commit 8cbefb7 into master May 5, 2022
guibou added a commit that referenced this pull request May 13, 2022
Support was broken by
#2866 where the
configuration-ghc-921 file was removed.

#2892 will indeed
restore these file and fix the build with GHC 922, but I was in need a
GHC 921 support at work.
sloorush pushed a commit to sloorush/haskell-language-server that referenced this pull request May 21, 2022
hololeap pushed a commit to hololeap/haskell-language-server that referenced this pull request Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants