-
Notifications
You must be signed in to change notification settings - Fork 710
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
Conversation
Uh, why does it timeout and why does it fail to install |
I think I was mistaken that |
Agreed, such refactor would be great if feasible. How could I find who left the comments? |
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. |
If there is going to be single source of truth for this, which module should it go? It seems Also, perhaps this is going outside my scope, as I was originally planned to do simple changes at 1 or 2 places. |
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. |
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: cabal/cabal-install/tests/UnitTests/Distribution/Solver/Modular/Solver.hs Lines 151 to 156 in 52cc82d
|
@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! |
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! |
Should I create test case for each of "ghc", "ghci", and "ghc-boot"? What error message should I check? |
e836d93
to
959ed3d
Compare
Sure, that sounds fine.
It looks like the error will contain either "only already installed instances can be used" or "constraint from non-upgradeable
You could either rename the "Base" test group to something more general and put it there or create a new one. |
@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 |
@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. |
959ed3d
to
ed80f71
Compare
Fixed accordingly. By the way, what is the checklist about? |
ghc
, ghc-boot
, ghci
packages should be non-upgradable (#8489)ghc
, ghc-boot
, ghci
packages should be non-upgradable (#8489)
How about |
Are these also boot libraries? Sorry, I do not know what "boot library" precisely means. |
@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 |
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. |
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! |
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.
Gershom's reasoning is convincing to me, and I have no other objections. Thank you for the contribution!
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 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" [] |
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 don't think that the base dependency is necessary. It would be simpler for each test to only involve one non-upgradable package.
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 thought it would add some realistic complexity, but I see it is better to remove it.
Updated accordingly. Should I also add EDIT: Also, should I keep rebasing onto the master? Or does Github PR machinary make my PR neatly contained in one commit anyway? |
fd2e62f
to
91e9137
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.
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.
, Right $ exAv "ghc" 2 [ExFix "base" 1] | ||
, Right $ exAv "ghci" 2 [ExFix "base" 1] | ||
, Right $ exAv "ghc-boot" 2 [ExFix "base" 1] |
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.
There are still three references to base here.
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.
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" |
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.
Thanks for syncing ghc-bignum, too.
@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? |
@grayjay Yep, of course. Thank you! |
Thanks for the fix! |
@Abastro: thanks for the PR. I've given you Triage rights so that you can apply labels yourself. |
…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>
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.