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

Support transformers-0.6 and mtl-2.3 #8144

Closed
phadej opened this issue May 17, 2022 · 10 comments · Fixed by #8610
Closed

Support transformers-0.6 and mtl-2.3 #8144

phadej opened this issue May 17, 2022 · 10 comments · Fixed by #8610
Assignees
Labels
re: dependencies Concerning Cabal's dependencies

Comments

@phadej
Copy link
Collaborator

phadej commented May 17, 2022

Looks like that relaxing bounds is enough.

@fgaz fgaz added the re: dependencies Concerning Cabal's dependencies label May 17, 2022
Mikolaj added a commit to Mikolaj/cabal that referenced this issue May 19, 2022
@Mikolaj
Copy link
Member

Mikolaj commented May 19, 2022

Actually, to have (full) effect, this requires a bump in hackage-security and a release or revision of it: haskell/hackage-security#272

@Mikolaj
Copy link
Member

Mikolaj commented May 19, 2022

That seems to be the case for cabal-install, but in CI it affects all, because they are built together, so old versions are forced, because cabal-install depends on hackage-security that depends on old transformers and mtl. Oh well.

@phadej
Copy link
Collaborator Author

phadej commented May 19, 2022

The CI was capable to build only Cabal and its tests, to allow testing Cabal as soon as there is new stuff (GHC, deps). I hope it's still the case. (allowing flexibility was a reason the templating was done in Haskell, and not YAML).

@Mikolaj
Copy link
Member

Mikolaj commented May 19, 2022

That makes sense, but I can't find a CI job running with newest GHC and compiling Cabal without cabal-install. @jneira, @andreabedini, is there such a job? The idea is that, unburdened by cabal-install dep constraints, it can catch early incompatibilities with newer versions of packages, GHC-related in particular. Testing packages introduce their own bounds, so perhaps it would make sense to compile without Cabal tests first, and then with tests and run them. Thoughts?

@Mikolaj Mikolaj self-assigned this May 19, 2022
@phadej
Copy link
Collaborator Author

phadej commented May 19, 2022

that what e.g. (from 3.2 branch)

, GhcJob "7.8.4" False "--lib-only" False ["8.8.3"] libSteps
job did, similar lib-only jobs were used for most recent GHC at the time too.

Implementation wise it was to run a subset of validate.sh steps, so shouldn't be difficult to (re)implement if it gone missing.

@andreabedini
Copy link
Collaborator

We can, see #8151

@Mikolaj
Copy link
Member

Mikolaj commented May 19, 2022

@phadej: thank you for the tip. Now that we actually understand what the "--lib-only" was for and that it wasn't supposed to stick with the same GHC forever, we can improve the new setup. :)

@Mikolaj Mikolaj added this to the Considered for 3.10 milestone Jul 14, 2022
Mikolaj added a commit to Mikolaj/cabal that referenced this issue Jul 21, 2022
@Bodigrim
Copy link
Collaborator

@Mikolaj what are the next steps here? Unless Cabal package allows transformers-0.6, the latter cannot be bundled as a GHC boot library, so almost everyone is tied to transformers-0.5, which is a shame, because transformers-0.6 has been around since July 2021.

At this point we do not really care about cabal-install or hackage-security, they may stick to older infrastructure for a while. But to bump a GHC submodule all boot libraries must be compatible with each other, and I believe Cabal is the last blocker for this to happen.

@Mikolaj
Copy link
Member

Mikolaj commented Nov 19, 2022

@Bodigrim: current master branch is fine, right? So it's the matter of including it in GHC? I have no problem with including today's snapshot in GHC, for now, but the final version for GHC 9.6 is tracked at #8571.

@Mikolaj
Copy link
Member

Mikolaj commented Nov 19, 2022

Oh, I see, master branch is fine after we merge #8610.

Still. Is that all or may I help further?

@mergify mergify bot closed this as completed in #8610 Nov 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
re: dependencies Concerning Cabal's dependencies
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants