Some questions for users on macOS

chreekat · December 12, 2022, 1:49pm

Hello,

Macs represent 1/3 of development platforms and deployment targets for Haskellers, but I myself haven’t used a Mac in about 15 years. I would like to know what it’s like to work with Haskell on a Mac.

I’d like to ask about one aspect of the experience in particular: getting set up. And the specific reason I’m asking about this is that notarizing GHC for Macs is currently on the to-do list.

Notarization is part of Apple’s fight against malware. Codesigning is another. I am still learning how they work and what the consequences are.

Does the lack of a notarized installable affect you? (Example of missing notarization here.) If so, how? It helps to be specific: Did you get started with GHCUp? Stack? Something else?

What other pain points exist when you (or your students/classmates/colleagues/bosses) get set up to work with Haskell? What’s the biggest pain point?

I’ll have access to a Mac soon, but I don’t want to base my effort on one data point.

Thanks!

-Bryan
Haskell Foundation DevOps

romes · December 12, 2022, 1:53pm

I have no issues with my macos GHCUP based GHC and cabal installation.

Other than GHC, I install some tools through brew the package manager. I wonder how they handle notarization, or why it’s not an issue for them.

I have a pretty smooth experience overall

chreekat · December 12, 2022, 1:56pm

Good to hear. Which version of macOS?

angerman · December 12, 2022, 2:09pm

I use (probably to not much surprise)

nix develop github:input-output-hk/devx#ghc8107 --no-write-lock-file --system aarch64-darwin

nix develop github:input-output-hk/devx#ghc8107 --no-write-lock-file --system x86_64-darwin

(or without the system argument if I want to use what ever the default is).

The by far biggest issue we have with mac is rather toolchain confusion. By this I mean that the toolchain and GHC end up in a state where GHC targets aarch64 and the toolchain x86_64 or the other way around. And then some minor cases where people upgraded llvm too aggressively.

Notarization of GHC itself has rarely been an issue. That likely only comes up if someone tries to install GHC from the Haskell.org bindists.

chreekat · December 12, 2022, 2:41pm

On the 2022 State of Haskell survey, there were 30 people (3%) who selected “MacOS” as a platform and “Official binaries” as an installation method. But both those questions were multi-select, so that represents an unlikely maximum bound on the number of people who actually use official binaries on Macs. I hope one of them sees this post.

romes · December 12, 2022, 3:30pm

macOs Monterey 12.6; 2017, Intel processor

hasufell · December 13, 2022, 12:30am

github.com

haskell/ghcup-hs/blob/823458910b41cf79739257dbc3d08084400bb594/lib/GHCup/Utils.hs#L1048

    
      
                        -> Excepts '[PatchFailed, DownloadFailed, DigestError, GPGError] m ()
          applyAnyPatch Nothing _                   = pure ()
          applyAnyPatch (Just (Left pdir)) workdir  = liftE $ applyPatches pdir workdir
          applyAnyPatch (Just (Right uris)) workdir = do
            tmpUnpack <- fromGHCupPath <$> lift withGHCupTmpDir
            forM_ uris $ \uri -> do
              patch <- liftE $ download uri Nothing Nothing tmpUnpack Nothing False
              liftE $ applyPatch patch workdir
          
          

          
-- | https://gitlab.haskell.org/ghc/ghc/-/issues/17353
          darwinNotarization :: (MonadReader env m, HasDirs env, MonadIO m)
                             => Platform
                             -> FilePath
                             -> m (Either ProcessError ())
          darwinNotarization Darwin path = exec
            "xattr"
            ["-r", "-d", "com.apple.quarantine", path]
            Nothing
            Nothing
          darwinNotarization _ _ = pure $ Right ()

This is what we do in ghcup when installing GHC. Basically "xattr" ["-r", "-d", "com.apple.quarantine", path]. I don’t think this is proper notarization.

I also remember issues with notarisation wrt ghcup binaries themselves, but it kinda went silent. Probably because users find easy workarounds?

github.com/haskell/ghcup-hs

ghcup mac binaries should be signed

opened 09:23PM - 26 Feb 22 UTC

hasufell

scope: platforms status: help-needed type: improvement

In GitLab by @simonmichael on Feb 27, 2022, 05:23 On macos monterrey (12.2.1) o…n m1, at least, the ghcup v0.1.17.5 binary installed by `ghcup upgrade` didn't run because of an invalid signature (probably disrupted by stripping). This has now been worked around by not stripping them. But such unsigned binaries are probably (can't recheck on my system) hard to run because of giving the "could not check for malicious software" warning, which must be bypassed eg in System Preferences > Security & Privacy for each new ghcup version. `codesign -s - BINARY` seems to be a way to fix stripped binaries, adding an adhoc signature and bypassing the warning. But ideally these binaries should be signed with an official Apple developer ID, to prove they are genuine. A Haskell Foundation developer ID or similar might be ideal.

rae · December 15, 2022, 12:25am

I used the official binaries for a while, and this was a fairly awful experience, requiring me to grant permission to each component of GHC separately (twice). It all took about 20 minutes. For a little while now, I’ve been using GHCup quite happily – no problem there.

If it’s the path of least resistance, I’d be happy to have GHCup be the only recommended way to get GHC on a Mac, rather than expend time and energy to get notarization working so that the direct binaries work.

chreekat · December 15, 2022, 9:40am

Thanks for the report! It really sounds like there aren’t many people trying to work with the official binaries directly, which I think is a good thing.

Cmdv · December 15, 2022, 10:40pm

I’ve been using osx/macos with Haskell for a good 5-6 years now and not really had too much trouble. I’m currently on M1 Monterey OS (12.6). Since GHCUP it’s been really easy entry point never any hassle to get going. I started with doing things manually, then Nix but at the time to bring in different versions of GHC would take 10-12 hours to build!!! (Pretty sure it’s not the case anymore!) then GHCUP arrive and left NIX behind.

The only thing that seems to not play well is HLS, I’ve become very accustomed to using it and love it. But over the past year on various releases I’ve had to spend quite some time to get things close to working. Can’t work out if it’s because I’m on Emacs/Doom and should really test it out on VS-Code as that seems to be the primary/most active use, to see if it is me being on emacs.

Anyways unsure if it has any relations. With MacOs I just hang fire before updating and wait for things to catch up before pulling the trigger when it come to GHC

Overall it’s been great

brandonchinn178 · December 17, 2022, 5:46pm

I’ve historically always used Stack’s GHC bootstrapping mechanism, and it’s been pretty seamless the whole time. I recently started using Stack+GHCup on the new Mac M2 arm chip, and thats also been seamless. No notarization issues. But notarization was an issue when I tried to download a beta version from haskell.org, as @rae said (accepting each file). I think I ran some command to accept everything int he directory, but I dont remember