-
Notifications
You must be signed in to change notification settings - Fork 704
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
Move most solver code to new module namespace #3381
Conversation
Can you also do a PR against the 1.24 branch then? |
In fact I've already asked @rthomas to cut a release, though he haven't responded yet.
No need to close this one, just make a new one againt 1.24. Though at this stage I can't guarantee it'll make it into the release. |
Nevermind the 1.24.x bit, I don't think it's really feasible unless loads of other stuff from master gets merged. I wasn't aware of how much they'd diverged already. |
OK, fine. |
Obviously, I'd still like this to get merged to master as soon as feasible -- it's still conflict-prone and I really don't want to have to do this a third(?) time because of conflicts :). |
d877695
to
4de48a2
Compare
4de48a2
to
1d101e6
Compare
If @kosmikus is OK with this, I can merge. |
(Sorry for the noise:) Just a little review note: Obviously there are no changes in any actual logic, it's all just about moving code around and fixing up imports. |
Yes, AFAICS, this is all ok. I'm not completely sure if I am somewhat worried about the interference with other ongoing developments. @23Skidoo, if we merge this, I think it's important that others (including, but by no means limited to @ezyang, @dcoutts, @grayjay, @hvr, @edsko) are fully aware that some modules now have switched / are about to switch location and can adapt to the new layout as soon as possible. It may also be good to include a full old-new conversion list somewhere where it can be easily referenced online. Apart from the concern just mentioned, though, I agree with @BardurArantsson that it is better to merge this sooner rather than later, because on one side of the spectrum, maintaining PRs such as this is tedious, and on the other side of the spectrum, others may hold off their own PRs that affect many modules if they know that a larger module reorganization is imminent. |
@23Skidoo Yes, but open PRs are not necessarily a reflection of all ongoing work. And this PR touches more than just the solver code. It moves all modules that the solver depends on into the |
#2917 also touches the solver. It will be easier to rebase if this is merged sooner, since I just rebased it today. |
OK, I think the consensus is that it's better to merge this earlier than later, so I'm merging. |
Merged, thanks! |
Great, thank you! I'll get started on the remaining minor bits & pieces. If there's enough interest, I can try to assemble a little list of "what moved where", but it should mostly hopefully be pretty obvious. |
Ha, just noticed that Cabal now has exactly 7000 commits! :) |
@BardurArantsson Thank you for your patience, and sorry that this had to go through multiple iterations to make progress. |
@kosmikus NP. (Sure, it's been a bit frustrating, but such is the nature of "Big Bang" changes.) |
This should basically be good to go as the first step in moving all the solver bits to a separate namespace. There are a few types left in
Client.Dependency.Types
-- I'll submit a follow-up for those sometime during the week if we can get this PR merged.I'm anxious to get this merged before 1.24.x if possible because a) it's generally pretty conflict-prone even though it's trivial code movement, and b) so that we don't spurious conflicts if we're going to cherry-pick bits from master into 1.24.x following 1.24.0.(EDIT: Nevermind that, I don't think it's really feasible unless loads of other stuff from master gets merged.)I've elected to move some type definitions into smaller modules under
Client.Solver.Types
. This means: