[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 mouse07410):

 > 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

 Respectfully disagree. One reason - it proved to because infeasible to
 provide Macports clones of all the packages maintained by other env-
 specific ecosystems. Python is the best example of that.

 For example, I use Macports not because I can't do {{{pip install
 pycryptodome}}}, but because it's convenient for me to, e.g., install a
 reasonable version of OpenSSL via {{{sudo port install openssl}}}
 (actually, a bad example - as one of the contributors, I do keep source
 tree of OpenSSL, and regularly rebuild master and stable branches ;).

 I see absolutely nothing wrong for the user to do {{{sudo port install
 gcc8 && pip-3.7 install numpy}}}. It does not seem much harder than
 {{{sudo port install py37-numpy}}}.

 >  Approaching this as "if you want pandoc, install cabal/stack and...

 Why would a Haskell user want to install {{{pandoc}}} via Macports??? Any
 more than installing {{{Haskell-libsodium}}} via Macports? Or <put your
 favorite Haskell package here>?

 Macports cannot and shouldn't become a substitute for ecosystem-specific
 package managers.

 >  Even just building stack with the current approach probably needs some
 kind of automation...

 Yes, non-trivial - which is why I'd be perfectly content packaging pre-
 built {{{stack}}} binary and keeping it. For example, my system uses pre-
 built {{{stack}}} - I did not rebuilt it, not do I want to. It works. I
 don't need Macports to provide it to me, nor do I feel like I'm obligated
 to rebuild it from sources.

 > It's the platform vs. no platform and libraries vs. not packaging
 libraries discussion that makes things complicated

 There already is {{{Haskell Platform}}}. The main reason I don't use it in
 its entirety is because it's GHC conflicts with Macports {{{libiconv}}}.
 So I had to rebuild GHC myself. But {{{stack}}} from {{{Haskell
 Platform}}} is perfectly usable as is. Whatever Haskell libraries I need -
 {{{stack}}} or {{{cabal}}} will install for me, and would do that the
 right way. No reason for Macports to try emulating that.

 > 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.

 **Yes**!! I strongly urge to revisit. Haskell ecosystem is very strong.
 It's neither needed nor possible to replicate it. The only reason I'm
 suggesting refreshing the port is because the default GHC provided by
 Haskel ecosystem conflicts with Macports. Everything else from Haskell eco
 coexists with Macports just fine, so no need to re-do it.

 > 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

 Now, **that** is an idea. But I'm getting concerned when I hear "to build
 ***all** tools" from you. My question is - since those tools are trivially
 installed by {{{stack}}}, what benefit is there in offering what
 essentially is a Macports wrapper for it? And is it worth the cost (time
 and efforts)? Is {{{sudo port install pandoc}}} really that much simpler
 than {{{stack install pandoc}}}, especially for somebody who presumably
 got GHC (with cabal and stack) because that somebody is developing within
 the Haskell ecosystem?

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