[MacPorts] #48899: ghc & haskell-platform update?

[MacPorts]

#48899: ghc & haskell-platform update?
-----------------------------------+------------------------
  Reporter:  J.Gilbey@…            |      Owner:  neverpanic
      Type:  update                |     Status:  assigned
  Priority:  Normal                |  Milestone:
 Component:  ports                 |    Version:
Resolution:                        |   Keywords:
      Port:  haskell-platform ghc  |
-----------------------------------+------------------------

Comment (by neverpanic):

 Replying to [comment:41 mouse07410]:
 > Some of them probably do something reasonable, and some - don't (in  my
 opinion). For example, IMHO what Macports Python does is crazy (IMHO), and
 causes unnecessary conflicts because, as I explained, there's no way for
 Macports to replicate he entire PYPI repo, so some packages get overridden
 when the user needs to install something, e.g., from PYPI and that thing
 pulls its own dependencies - again directly from PYPI.

 I think the current approach is supposed to be "package everything that
 needs native dependencies". The question of native dependencies is where
 the whole approach of "don't package any of the libraries" falls apart,
 because users use MacPorts precisely to avoid having to compile their own
 copy of `$library_used_by_python_module` or to figure out how to get the
 Python build system to find MacPorts' copy of said library.


 > Leaving the packages to the corresponding infrastructure, and providing
 just the "main" binaries - {{{ghc}}}, {{{cabal}}}, and {{{stack}}} - would
 be best. And simplest too.

 Back when we originally packaged GHC, we were told by the Haskell
 community that we should really be providing GHC "batteries included" by
 packaging the haskell platform. Maybe it is time to revisit this decision.

 However, keep in mind that many users will expect packages such as pandoc
 and shellcheck to be available from MacPorts. Approaching this as "if you
 want pandoc, install cabal/stack and run `cabal/stack install pandoc`" is
 not the best alternative from a UX perspective – especially since we don't
 have a good way to communicate this exception to the common usage of
 MacPorts.


 > Then, BTW, you won't need to bother with the unnecessary dependency on
 LLVM. I just rebuilt GHC from the sources, and it was smooth as castor
 oil. Why Macport GHC port can't do the same? Don't overcomplicate things -
 KISS rules.

 The LLVM dependency isn't the issue here, I think. Building a newer
 version of GHC isn't very complicated. It's the platform vs. no platform
 and libraries vs. not packaging libraries discussion that makes things
 complicated.

 Btw, `stack` has hundreds of dependencies – it's what kept me from
 finishing the packaging of a current version of haskell-platform. Even
 just building stack with the current approach probably needs some kind of
 automation.


 > If the maintainers feel married to the current approach - let's leave
 the current (ancient) port of ghc-7.8.3 alone, with all the goodies it
 offers, and add another "minimalistic" port of ghc-8.6.3 that provides
 only {{{ghc}}} (**not** dependent on LLVM!), {{{cabal}}}, and {{{stack}}}.
 Everything else users can install themselves just fine.

 I'm not married to that approach. If you want to submit patches to update
 the GHC port and drop haskell-platform as well as the other Haskell ports,
 I'm fine with that. I don't have a strong opinion on LLVM or not (although
 I don't believe it's a big problem), however, I would expect commonly used
 ports such as pandoc and shellcheck to be available from MacPorts. If you
 can provide that plus a copy of stack, that'd be great.

 Maybe a good approach would also be to build all tools (such as pandoc)
 using stack from a Portfile, so that they all ship their dependencies in a
 private folder. We've recently adopted a similar approach for ports using
 rust's cargo. See the `cargo 1.0` PortGroup, for example.

-- 
Ticket URL: <https://trac.macports.org/ticket/48899#comment:43>
MacPorts <https://www.macports.org/>
Ports system for macOS