Skip to content

ghc, ghc-boot, ghci packages should be non-upgradable (#8489) #8501

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

Merged
merged 10 commits into from
Nov 9, 2022

Conversation

Abastro
Copy link
Collaborator

@Abastro Abastro commented Sep 29, 2022


Please include the following checklist in your PR:

Fixes #8489 (was not able to check if it is fixed myself, though)

Just adding a few in a non-upgradable package list, so this should be a simple change without major breakages.

I would love to add tests to check if those packages are correctly marked as non-upgradable, but I do not know how.
I would like to know how to add such tests.

@Abastro
Copy link
Collaborator Author

Abastro commented Sep 29, 2022

Uh, why does it timeout and why does it fail to install changelog-d?

@gbaz
Copy link
Collaborator

gbaz commented Sep 29, 2022

I think I was mistaken that nonInstallable doesn't need to be updated. I think it should be as well. I would also consider it a good refactor to export the list canonically from Cabal and then to have the solver import and use it, rather than needing to update two places independently and keep them in sync. (perhaps worth asking whoever left the comments why they didn't do so to begin with?)

@Abastro
Copy link
Collaborator Author

Abastro commented Sep 30, 2022

Agreed, such refactor would be great if feasible. How could I find who left the comments?

@belka-ew
Copy link

belka-ew commented Oct 1, 2022

Agreed, such refactor would be great if feasible. How could I find who left the comments?

With git blame cabal-install/src/Distribution/Client/Dependency.hs you'll find the commit that introduced the change, it's 0eb4e51, @hvr.

@gbaz
Copy link
Collaborator

gbaz commented Oct 1, 2022

The duplication was introduced prior to the comments, which just documented it. I think this wasn't planned, just accidental complexity. So I vote try the consolidation refactor and see what happens.

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 2, 2022

If there is going to be single source of truth for this, which module should it go? It seems cabal-install-solver is a common dependency, but I guess it could go into Cabal itself. I do not know much about how these libraries are split around.

Also, perhaps this is going outside my scope, as I was originally planned to do simple changes at 1 or 2 places.

@gbaz
Copy link
Collaborator

gbaz commented Oct 2, 2022

Sure -- if you don't want to do a bigger refactor, just solving the immediate issue is fine, and that refactor can be done at a later date.

@grayjay
Copy link
Collaborator

grayjay commented Oct 6, 2022

I would love to add tests to check if those packages are correctly marked as non-upgradable, but I do not know how.
I would like to know how to add such tests.

You could add a unit test to cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs. I think you could write a test that uses a package repository with an installed version of ghc, a newer source version of ghc, and a package that depends on the newer version of ghc. The solver should fail to find a solution, and the test could also check the error message. Here are some related tests:

, testGroup "Base" [
runTest $ mkTest dbBase "Refuse to install base without --allow-boot-library-installs" ["base"] $
solverFailure (isInfixOf "only already installed instances can be used")
, runTest $ allowBootLibInstalls $ mkTest dbBase "Install base with --allow-boot-library-installs" ["base"] $
solverSuccess [("base", 1), ("ghc-prim", 1), ("integer-gmp", 1), ("integer-simple", 1)]
]

@ulysses4ever
Copy link
Collaborator

@Abastro do you have any trouble with grayjay’s suggestion above? It should be reasonably straightforward, and we’re always happy to explain in more detail. Otherwise, great job here, and I’m looking forward for your patch to be merged!

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 22, 2022

Sorry for long hiatus, I was busy with academy work. As soon as I get some time, I will add tests with grayjay's suggestions!

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 23, 2022

Should I create test case for each of "ghc", "ghci", and "ghc-boot"? What error message should I check?
Also, which test group should this test belong to?

@grayjay
Copy link
Collaborator

grayjay commented Oct 24, 2022

Should I create test case for each of "ghc", "ghci", and "ghc-boot"?

Sure, that sounds fine.

What error message should I check?

It looks like the error will contain either "only already installed instances can be used" or "constraint from non-upgradeable
package requires installed instance". I'm not sure which error takes precedence.

Also, which test group should this test belong to?

You could either rename the "Base" test group to something more general and put it there or create a new one.

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 24, 2022

@grayjay Currently I check directly against the whole error message:

solverFailure . isInfixOf $
                    "Could not resolve dependencies:\n"
               ++ "[__0] trying: A-1.0.0 (user goal)\n"
               ++ "[__1] next goal: ghc (dependency of A)\n"
               ++ "[__1] rejecting: ghc-1.0.0/installed-1 (conflict: A => ghc==2.0.0)\n"
               ++ "[__1] rejecting: ghc-2.0.0 (constraint from non-upgradeable package requires installed instance)\n"
               ++ "[__1] fail (backjumping, conflict set: A, ghc)\n"
               ++ "After searching the rest of the dependency tree exhaustively, "
                    ++ "these were the goals I've had most trouble fulfilling: A, ghc

Should I rather check for solverFailure . isInfixOf "constraint from non-upgradeable package requires installed instance"?

@grayjay
Copy link
Collaborator

grayjay commented Oct 25, 2022

@Abastro I think it would be better to only check that the error message contains "rejecting: ghc-2.0.0 (constraint from non-upgradeable package requires installed instance)", because that ensures that the correct type of error occurs and that it relates to the source version of ghc. The rest of the message isn't really relevant and makes the test more susceptible to failing after other unrelated changes to solver error messages.

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 25, 2022

Fixed accordingly. By the way, what is the checklist about?

@Abastro Abastro changed the title WIP: ghc, ghc-boot, ghci packages should be non-upgradable (#8489) ghc, ghc-boot, ghci packages should be non-upgradable (#8489) Oct 25, 2022
@ulysses4ever
Copy link
Collaborator

How about ghc-boot-th, ghc-compact, ghc-heap? That's what I see here: https://gitlab.haskell.org/ghc/ghc/-/tree/master/libraries

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 25, 2022

Are these also boot libraries? Sorry, I do not know what "boot library" precisely means.

@Kleidukos
Copy link
Member

@Abastro Hi! A list of boot libraries can be viewed for each GHC release in its release notes. For example: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html#included-libraries

@ulysses4ever
Copy link
Collaborator

ulysses4ever commented Oct 25, 2022

I'm afraid "non-upgradable" is not exactly the same as "boot". E.g. bytestring is boot (meaning, it comes with GHC), but you can compile and use a version of it that's newer than what comes with your GHC. On the other hand, you can't use template-haskell or ghc-prim of a version different from what comes with your GHC.

Please, someone with more knowledge, sanity-check what I'm saying here. That's just the way I understand it but I don't know of any documentation that proves what I say here.

@gbaz
Copy link
Collaborator

gbaz commented Oct 25, 2022

The above is correct. I'm fine with the PR as is. I agree that there are probably a few other non-upgradable libraries that still aren't in the list as we've amended it, but I'm not sure how to determine what they are for certain, and would much rather that we just solve things we know to be problems!

Copy link
Collaborator

@ulysses4ever ulysses4ever left a comment

Choose a reason for hiding this comment

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

Gershom's reasoning is convincing to me, and I have no other objections. Thank you for the contribution!

Copy link
Collaborator

@grayjay grayjay left a comment

Choose a reason for hiding this comment

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

I think we should continue to also update the list in Distribution.Solver.Modular.Solver until we try to remove it. It would be confusing if cabal handled different non-upgradable packages differently, if the two lists had subtly different behavior.

@@ -1123,6 +1129,22 @@ dbBase = [
, Right $ exAv "integer-gmp" 1 []
]

dbNonupgrade :: ExampleDb
dbNonupgrade =
let base = exInst "base" 1 "base-1" []
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think that the base dependency is necessary. It would be simpler for each test to only involve one non-upgradable package.

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 thought it would add some realistic complexity, but I see it is better to remove it.

@Abastro
Copy link
Collaborator Author

Abastro commented Oct 27, 2022

Updated accordingly. Should I also add ghc-boot-th, ghc-compact, ghc-heap in? I guess ghc-boot-th is template-haskell related, so that one might need to be in. I am not sure what the other two does..

EDIT: Also, should I keep rebasing onto the master? Or does Github PR machinary make my PR neatly contained in one commit anyway?

Copy link
Collaborator

@grayjay grayjay left a comment

Choose a reason for hiding this comment

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

Updated accordingly. Should I also add ghc-boot-th, ghc-compact, ghc-heap in? I guess ghc-boot-th is template-haskell related, so that one might need to be in. I am not sure what the other two does..

I'm not sure how to determine whether a GHC package is upgradable, so I'll let others review that part.

EDIT: Also, should I keep rebasing onto the master? Or does Github PR machinary make my PR neatly contained in one commit anyway?

If I understand correctly, Mergify can be made to squash a PR by applying a specific label.

Comment on lines 1137 to 1139
, Right $ exAv "ghc" 2 [ExFix "base" 1]
, Right $ exAv "ghci" 2 [ExFix "base" 1]
, Right $ exAv "ghc-boot" 2 [ExFix "base" 1]
Copy link
Collaborator

Choose a reason for hiding this comment

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

There are still three references to base here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm, strange that the test passed. Will fix!

@@ -162,7 +162,11 @@ solve sc cinfo idx pkgConfigDB userPrefs userConstraints userGoals =
nonInstallable =
L.map mkPackageName
[ "base"
, "ghc-bignum"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for syncing ghc-bignum, too.

@grayjay
Copy link
Collaborator

grayjay commented Nov 7, 2022

@Abastro Can I apply the "squash+merge me" label, since this PR looks ready to merge, and the commits look like they should be combined?

@Abastro
Copy link
Collaborator Author

Abastro commented Nov 7, 2022

@grayjay Yep, of course. Thank you!

@grayjay grayjay added the squash+merge me Tell Mergify Bot to squash-merge label Nov 7, 2022
@grayjay
Copy link
Collaborator

grayjay commented Nov 7, 2022

Thanks for the fix!

@Mikolaj
Copy link
Member

Mikolaj commented Nov 7, 2022

@Abastro: thanks for the PR. I've given you Triage rights so that you can apply labels yourself.

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Nov 9, 2022
@mergify mergify bot merged commit 09c90de into haskell:master Nov 9, 2022
alexbiehl pushed a commit to alexbiehl/cabal that referenced this pull request Dec 15, 2022
…8489) (haskell#8501)

* ghc, ghc-boot, ghci should be non-upgradable

* (PR number)

* Checks for depending on GHC

* Also tests ghc-boot, ghci

* Simplify condition

* Added "rejecting:" bits

* Synced cabal-install-solver's list & Simplify testcase

* Updated changelog

* Fully remove base dependency in test dbNonUpgrade

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days squash+merge me Tell Mergify Bot to squash-merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

process >= 1.6.14 requires ghc-9.2.4 to be built again, which causes error
7 participants