#ghcup — Public Fediverse posts

#haskell #ghcup discovery

If like me, you use ghcup tui, and constantly find yourself pressing "u" thinking it means "use" only to find it means "uninstall", you can change the keybindings by editing ~/.ghcup/config.yaml

key-bindings:
  uninstall:
    KChar: 'r'
  set:
    KChar: 'u'

https://github.com/haskell/ghcup-hs/blob/a847ce6d2daa5e92a2a719cc5c4c9f1ae66e98ff/data/config.yaml#L24

#haskell #ghcup discovery

If like me, you use ghcup tui, and constantly find yourself pressing "u" thinking it means "use" only to find it means "uninstall", you can change the keybindings by editing ~/.ghcup/config.yaml

key-bindings:
  uninstall:
    KChar: 'r'
  set:
    KChar: 'u'

https://github.com/haskell/ghcup-hs/blob/a847ce6d2daa5e92a2a719cc5c4c9f1ae66e98ff/data/config.yaml#L24

#haskell #ghcup discovery

If like me, you use ghcup tui, and constantly find yourself pressing "u" thinking it means "use" only to find it means "uninstall", you can change the keybindings by editing ~/.ghcup/config.yaml

key-bindings:
  uninstall:
    KChar: 'r'
  set:
    KChar: 'u'

https://github.com/haskell/ghcup-hs/blob/a847ce6d2daa5e92a2a719cc5c4c9f1ae66e98ff/data/config.yaml#L24

#haskell #ghcup discovery

If like me, you use ghcup tui, and constantly find yourself pressing "u" thinking it means "use" only to find it means "uninstall", you can change the keybindings by editing ~/.ghcup/config.yaml

key-bindings:
  uninstall:
    KChar: 'r'
  set:
    KChar: 'u'

https://github.com/haskell/ghcup-hs/blob/a847ce6d2daa5e92a2a719cc5c4c9f1ae66e98ff/data/config.yaml#L24

@dpwiz I can deeply empathize. I almost stopped using Nix for my project. I kept pushing because it feels like a better setup than #ghcup (there's one quirk [?] that really bothered me here, in particular). It's very attractive with respect to a development env in Haskell in my opinion, but Nix sometimes feels like it causes bigger headaches.

Also thank you for mentioning this, it makes me feel less like a fool.

@dpwiz I can deeply empathize. I almost stopped using Nix for my project. I kept pushing because it feels like a better setup than #ghcup (there's one quirk [?] that really bothered me here, in particular). It's very attractive with respect to a development env in Haskell in my opinion, but Nix sometimes feels like it causes bigger headaches.

Also thank you for mentioning this, it makes me feel less like a fool.

@dpwiz I can deeply empathize. I almost stopped using Nix for my project. I kept pushing because it feels like a better setup than #ghcup (there's one quirk [?] that really bothered me here, in particular). It's very attractive with respect to a development env in Haskell in my opinion, but Nix sometimes feels like it causes bigger headaches.

Also thank you for mentioning this, it makes me feel less like a fool.

@dpwiz I can deeply empathize. I almost stopped using Nix for my project. I kept pushing because it feels like a better setup than #ghcup whose binaries I think are compiled to ignore #haddock comments to some extent so in #vscode the tooltips do not show the Haddock documentation for added (?) dependencies. It's very attractive with respect to a development env in Haskell in my opinion, but Nix sometimes feels like it causes bigger headaches.

@dpwiz I can deeply empathize. I almost stopped using Nix for my project. I kept pushing because it feels like a better setup than #ghcup whose binaries I think are compiled to ignore #haddock comments to some extent so in #vscode the tooltips do not show the Haddock documentation for added (?) dependencies. It's very attractive with respect to a development env in Haskell in my opinion, but Nix sometimes feels like it causes bigger headaches.

I kinda feel like #nix (nixpkgs?) is better than #ghcup for what I use it for.

I kinda feel like #nix (nixpkgs?) is better than #ghcup for what I use it for.

I kinda feel like #nix (nixpkgs?) is better than #ghcup for what I use it for.

I kinda feel like #nix (nixpkgs?) is better than #ghcup for what I use it for.

I kinda feel like #nix (nixpkgs?) is better than #ghcup for what I use it for.

Also moved to #ghcup on #macos which makes managing compilers and cabal a bit more streamlined. #haskell

Also moved to #ghcup on #macos which makes managing compilers and cabal a bit more streamlined. #haskell

Also moved to #ghcup on #macos which makes managing compilers and cabal a bit more streamlined. #haskell

Also moved to #ghcup on #macos which makes managing compilers and cabal a bit more streamlined. #haskell

Also moved to #ghcup on #macos which makes managing compilers and cabal a bit more streamlined. #haskell

Potential #haskell productivity boost ⚠️

I think the #GHC binaries from #ghcup are compiled to ignore Haddock comments (for "non-builtin" depends), so they don't show up in #vscode.

I'm using this Nix Flake template: https://zero-to-flakes.com/haskell-flake/start/

I maybe changed 1 line in the default flake (ghc92) and now see pic.

#cabal + #nixpkgs for depends 💯

I think this all lets you use same HLS, GHC, and Cabal as me, + reproduce my builds, run tests, with 1 or 2 commands.

#nix is reproducible magic.

Potential #haskell productivity boost ⚠️

I think the #GHC binaries from #ghcup are compiled to ignore Haddock comments (for "non-builtin" depends), so they don't show up in #vscode.

I'm using this Nix Flake template: https://zero-to-flakes.com/haskell-flake/start/

I maybe changed 1 line in the default flake (ghc92) and now see pic.

#cabal + #nixpkgs for depends 💯

I think this all lets you use same HLS, GHC, and Cabal as me, + reproduce my builds, run tests, with 1 or 2 commands.

#nix is reproducible magic.

Potential #haskell productivity boost ⚠️

I think the #GHC binaries from #ghcup are compiled to ignore Haddock comments (for "non-builtin" depends), so they don't show up in #vscode.

I'm using this Nix Flake template: https://zero-to-flakes.com/haskell-flake/start/

I maybe changed 1 line in the default flake (ghc92) and now see pic.

#cabal + #nixpkgs for depends 💯

I think this all lets you use same HLS, GHC, and Cabal as me, + reproduce my builds, run tests, with 1 or 2 commands.

#nix is reproducible magic.

Potential #haskell productivity boost ⚠️

I think the #GHC binaries from #ghcup are compiled to ignore Haddock comments (for "non-builtin" depends), so they don't show up in #vscode.

I'm using this Nix Flake template: https://zero-to-flakes.com/haskell-flake/start/

I maybe changed 1 line in the default flake (ghc92) and now see pic.

#cabal + #nixpkgs for depends 💯

I think this all lets you use same HLS, GHC, and Cabal as me, + reproduce my builds, run tests, with 1 or 2 commands.

#nix is reproducible magic.

Potential #haskell productivity boost ⚠️

I think the #GHC binaries from #ghcup are compiled to ignore Haddock comments (for "non-builtin" depends), so they don't show up in #vscode.

I'm using this Nix Flake template: https://zero-to-flakes.com/haskell-flake/start/

I maybe changed 1 line in the default flake (ghc92) and now see pic.

#cabal + #nixpkgs for depends 💯

I think this all lets you use same HLS, GHC, and Cabal as me, + reproduce my builds, run tests, with 1 or 2 commands.

#nix is reproducible magic.

I can't seem to manage to get documentation (beyond type signatures) to pop up in #vscode for #haskell code (my tooling is managed with #ghcup), the way it does for the "builtin" functions.

Does anyone know what this is about?

I can't seem to manage to get documentation (beyond type signatures) to pop up in #vscode for #haskell code (my tooling is managed with #ghcup), the way it does for the "builtin" functions.

Does anyone know what this is about?

I can't seem to manage to get documentation (beyond type signatures) to pop up in #vscode for #haskell code (my tooling is managed with #ghcup), the way it does for the "builtin" functions.

Does anyone know what this is about?

@fosskers Agreed. The one criticism I have is that when you install something, the download info and progress bar is just written over the UI (wherever the cursor happens to be), creating a total visual mess. But apart from that, #ghcup is very nice.

@fosskers Agreed. The one criticism I have is that when you install something, the download info and progress bar is just written over the UI (wherever the cursor happens to be), creating a total visual mess. But apart from that, #ghcup is very nice.

@fosskers Agreed. The one criticism I have is that when you install something, the download info and progress bar is just written over the UI (wherever the cursor happens to be), creating a total visual mess. But apart from that, #ghcup is very nice.

@fosskers Agreed. The one criticism I have is that when you install something, the download info and progress bar is just written over the UI (wherever the cursor happens to be), creating a total visual mess. But apart from that, #ghcup is very nice.

@fosskers Agreed. The one criticism I have is that when you install something, the download info and progress bar is just written over the UI (wherever the cursor happens to be), creating a total visual mess. But apart from that, #ghcup is very nice.

Oh! So I get to learn just enough about #ghcup to become dangerous! Excellent.

Oh! So I get to learn just enough about #ghcup to become dangerous! Excellent.

Oh! So I get to learn just enough about #ghcup to become dangerous! Excellent.

Oh! So I get to learn just enough about #ghcup to become dangerous! Excellent.

Oh! So I get to learn just enough about #ghcup to become dangerous! Excellent.

Or without #stack using a simple #cabal-based project structure I often start with plus #ghcup for the tools. I can't get either of these simple workflows out of #nix.

Or without #stack using a simple #cabal-based project structure I often start with plus #ghcup for the tools. I can't get either of these simple workflows out of #nix.

Or without #stack using a simple #cabal-based project structure I often start with plus #ghcup for the tools. I can't get either of these simple workflows out of #nix.

Or without #stack using a simple #cabal-based project structure I often start with plus #ghcup for the tools. I can't get either of these simple workflows out of #nix.

Can anyone link me to what's new in #GHC 9 and I think there's also a what's new or some kind of language draft or something for #Haskell language and maybe #Cabal that goes over all the language pragmas/extensions enabled by default in the new version.

What should I be very aware of? I've been sticking with the versions #ghcup suggest to me--so right now I'm on GHC 8.10.7.

Can anyone link me to what's new in #GHC 9 and I think there's also a what's new or some kind of language draft or something for #Haskell language and maybe #Cabal that goes over all the language pragmas/extensions enabled by default in the new version.

What should I be very aware of? I've been sticking with the versions #ghcup suggest to me--so right now I'm on GHC 8.10.7.

Can anyone link me to what's new in #GHC 9 and I think there's also a what's new or some kind of language draft or something for #Haskell language and maybe #Cabal that goes over all the language pragmas/extensions enabled by default in the new version.

What should I be very aware of? I've been sticking with the versions #ghcup suggest to me--so right now I'm on GHC 8.10.7.

From what I can see, writing a #haskell #buildpack for #heroku is basically a #bash script one could write to set up haskell on a matching Linux distro. So all I need is to find a way to script the steps I took to get there. That might not be easy: I can't predict whether #ghcup is going to work on Heroku. Who here has tried that and can share their experiences?

From what I can see, writing a #haskell #buildpack for #heroku is basically a #bash script one could write to set up haskell on a matching Linux distro. So all I need is to find a way to script the steps I took to get there. That might not be easy: I can't predict whether #ghcup is going to work on Heroku. Who here has tried that and can share their experiences?

So that finally installed. Oh dear #ghcup maintainers: does it have to be so slow and involved? Every time I get to install #haskell on a fresh environment I have to look up how to do it, because it isn't obvious, and the packages available from package managers always prove out of date or incompatible.

So that finally installed. Oh dear #ghcup maintainers: does it have to be so slow and involved? Every time I get to install #haskell on a fresh environment I have to look up how to do it, because it isn't obvious, and the packages available from package managers always prove out of date or incompatible.