[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:44 mouse07410]:
 > 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}}}.

 That's fine if (and only if) the `pip-3.7 install numpy` will work out of
 the box. It usually does with stuff in `/usr/local`, but making your pip
 find stuff in `/opt/local` commonly requires flags. Additionally, using
 MacPorts pip will put files in MacPorts prefix that MacPorts doesn't know
 about, which has previously led to problems. We want to avoid that.


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

 Because people don't (and shouldn't) care that pandoc or shellcheck are
 written in Haskell. They just want the tool.


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

 Sure, but given this argument, we might as well not package Haskell at all
 in MacPorts. We could just remove it and tell people to use the upstream
 binaries provided by the GHC developers.


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

 Hm, that's weird. Binaries on macOS reference their libraries using
 absolute paths, and the upstream GHC binary shouldn't link against
 `/opt/local/lib/libiconv.2.dylib`, so unless you have `DYLD_LIBRARY_PATH`
 in your environment, the upstream Haskell Platform should just work. Have
 you looked into why that's not the case?

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

 You're making a few assumptions here that I don't think are correct:

 - I'm not trying to put an emphasis on **all** tools, but an emphasis on
 **tools**, i.e. it wouldn't make sense to package libraries in this way.
 - The benefit of having those wrapped is that you have a single way to
 update them and a single interface to manage them. I don't want to have to
 care about five different language-specific package managers when all I
 want is a single end-user tool.
 - Most of the Haskell stuff is distributable, so our build servers will
 provide precompiled binaries. This significantly speeds up installation.
 - Given sufficient automation (and none of the dependency hell), the time
 required to do this would probably not be very high, i.e. the cost would
 be low. In my eyes, that would make it worth the effort.

 I agree there's not a big difference for somebody who develops in the
 Haskell ecosystem, but those people really don't need our help in figuring
 this out anyway.

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