feat: migrate to vty-crossplatform and brick-2 #2128
Conversation
ShrykeWindgrace
changed the title
|
Very cool ! I see vty-windows is requiring GHC 9.4.4+. I'm thinking about this for hledger. It would be pleasant, but a big jump from 8.10 which I think would hurt our packageability ? Debian stable has 9.0 but Debian unstable has 9.4. No Ubuntu version has a GHC newer than 9.0. But I guess it wouldn't be the end of the world. 8.10 is 3.5y old (2020) and 9.4 is 1y old (2022). |
|
@simonmichael I did not take that aspect into account, to be honest. I know that Come to think of that, it appears you don't have to worry about And on windows builders you are free to do whatever you want. |
hledger-ui/package.yaml
Outdated
| - vty >=5.15 && <6 | ||
| - unix | ||
| - brick >=2.1.1 && <3 | ||
| - vty >=6.1 && <7 |
There was a problem hiding this comment.
API changes are not unknown in these packages, I think we'd better put tighter upper bounds (<2.2 <2.3, <6.2) even though it's a hassle.
There was a problem hiding this comment.
Still need these tighter upper bounds, though I can do it as a fixup.
There was a problem hiding this comment.
At least on Arch, brick 2.2 also works, so perhaps a bound of < 2.3 is also appropriate for brick. On Stackage, it's available in Stackage Nightly 2023-12-19.
There was a problem hiding this comment.
brick-2.2 is an enhancement over 2.1; judging by the changelog, there are no API changes.
There was a problem hiding this comment.
API changes are not unknown in these packages, I think we'd better put tighter upper bounds (
<2.2<2.3, <6.2) even though it's a hassle.
Already did that for 2.2/6.2, can bump brick to <2.3 if you want.
edit, I think I got it - I most probably changed only yaml files, not cabal. Done!
Just mention that
I edited my previous comment. It seems that would not be necessary for packaging on non-windows OSes.
Thanks! I'll iron out the extra-deps and dependencies for non-windows OSes soon(ish)=) |
Darn! |
ShrykeWindgrace
force-pushed
the
master
branch
from
5e6f125
to
5e7cfeb
Compare
|
It looks like the right fix might be to add the newer packages in stack9.4.yaml.? |
|
Hi, I'm in the process of updating the Arch packages to GHC 9.6 and For my part, I can confirm that this patch works for Arch. I also tested with -- Vekhir |
Hi! Thanks for maintaining that package=) From my part - nothing software-related, just plain old lack of time because of end-of-the-year festivities and day job workload=) I'll try to move the PR forward this week. |
Introduced or bumped dependencies: - brick-2.1.1 - vty-6.1 - vty-crossplatform-0.4.0.0 - vty-windows-0.2.0.1 conditionally on windows (current version of vty-crossplatform has 0.2.0.0 as a lower bound, need to put a newer version explcitly; once we get a newer vty-crossplatform, we will be able to drop this conditional) - vty-unix (indirectly via vty-crossplatform)
ShrykeWindgrace
force-pushed
the
master
branch
from
5e7cfeb
to
9890f46
Compare
Just did that=) |
There was a problem hiding this comment.
@ShrykeWindgrace looking good, let's add the tighter upper bounds requested, and let's clarify the situation with minimum GHC requirement: I think we found requiring GHC 9.4+ isn't strictly necessary, but as it stands this PR makes hledger require GHC 9.4+, and I'm ok with trying this, but I wonder what's the experience now when you try to build with an older GHC. Shouldn't we bump the lower base bound in the hledger packages also to make our GHC requirement explicit.
|
https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history has the GHC/base versions. base 4.17.0.0 allows GHC 9.4.0-4, we could require base 4.17.1.0 (GHC 9.4.5+) if it ensures a clearer build failure for installers. |
Thanks!
I thought I did that. What did I miss?
If I understand correctly, this PR makes a ghc-9.4+ a requirement only on windows. Other OSes should not be impacted.
I do not have a good vision on how people build and package |
|
Ok, I'm always trying to smooth the haskell build experience as much as we can, but I'm just going to merge this and we'll see how it shakes out. Thank you very much ! |
Addresses #2112
Incidentally, this adds support for
hledger-uifor windows in Windows Terminal.Current state of support of various features in different terminal emulators on Windows is tracked here: chhackett/vty-windows#15 with visualization here: https://github.com/chhackett/vty-windows/wiki/TerminalSupport (WIP). Rule of thumb - if emulator is mintty-based (defaults for cygwin, git bash, msys2), the app will fail. If it is conhost-based (Windows-Terminal, Wezterm) the app will work. If its a conhost-based-but-opinionated (Alacritty), almost everything will work.
I have not yet started proper documentation for
hledger-ui, but I think that in most cases it will be safe to redirect them tovty-windowsoutright.Also I have not touched CI/releases/packaging. The builds should pass for sufficiently recent GHC (I think ghc-9.4.4 should be enough. ghc-8.* most probably won't work).