[WIP] Fix broken Haskell world #5050

amake · 2019-08-19T15:36:50Z

Description

#4699 / #4794 bumped the ghc port, but in doing so appears to have broken the entire Haskell world. These important comments in the ghc portfile were deleted without explanation or action:

# Do not update GHC separate from Haskell Platform.
# When updating GHC, make sure to revbump all Haskell ports.
# Also make sure to update the version in the Haskell PortGroup.

Now, for instance, all existing Haskell library port binaries will install but fail to be found because they install to ${prefix}/lib/ghc-7.8.3 instead of -8.6.5.

This PR attempts to address all of this, but it's a lot of work so I will do it incrementally.

Type(s)

bugfix
enhancement
security fix

Tested on

macOS 10.14.6 18G87
Xcode 10.3 10G8

Verification

Have you

followed our Commit Message Guidelines?
squashed and minimized your commits?
checked that there aren't other open pull requests for the same change?
referenced existing tickets on Trac with full URL?

checked your Portfile with port lint?
tried existing tests with sudo port test?
tried a full install with sudo port -vst install?
tested basic functionality of all binary files?

grep -lR 'PortGroup.*haskell' . | xargs -n 1 sh -c "awk '/revision/{sub(/[[:digit:]]+/,\$NF+1)}1' \$0 > \$0.new; mv \$0.new \$0"

The version has been removed from the homepage, so use GitHub instead.

TODO: Figure out how to handle lost epoch (subports don't allow epoch?)

macportsbot · 2019-08-19T15:36:57Z

Notifying maintainers:
@neverpanic for port darcs, haskell-platform, hs-aeson, hs-asn1-data, hs-asn1-types, hs-base-unicode-symbols, hs-base64-bytestring, hs-bloomfilter, hs-byteable, hs-cereal, hs-certificate, hs-cipher-aes, hs-cipher-rc4, hs-citeproc, hs-conduit, hs-connection, hs-cookie, hs-cprng-aes, hs-crypto-api, hs-crypto-cipher-types, hs-crypto-numbers, hs-crypto-pubkey-types, hs-crypto-pubkey, hs-crypto-random, hs-cryptohash, hs-curl, hs-data-accessor-template, hs-diff, hs-dlist, hs-download-curl, hs-edisonapi, hs-edisoncore, hs-edit-distance, hs-entropy, hs-exceptions, hs-extensible-exceptions, hs-failure, hs-fclabels, hs-feed, hs-fingertree, hs-haskeline, hs-hinstaller, hs-hs3, hs-hslua, hs-http-client-conduit, hs-http-client-tls, hs-http-client, hs-http-conduit, hs-http-types, hs-hxt-charproperties, hs-hxt-regex-xmlschema, hs-hxt-unicode, hs-hxt, hs-ifelse, hs-ipatch, hs-lifted-base, hs-memotrie, hs-missingh, hs-mmorph, hs-monad-control, hs-nats, hs-numinstances, hs-pem, hs-pointedlist, hs-polyparse, hs-publicsuffixlist, hs-puremd5, hs-readline, hs-regex-tdfa, hs-resourcet, hs-rosezipper, hs-securemem, hs-semigroups, hs-socks, hs-storable-complex, hs-string-qq, hs-tagged, hs-tagsoup-0.12, hs-tar, hs-terminfo, hs-texmath, hs-tls-extra, hs-tls, hs-transformers-base, hs-type-level, hs-utility-ht, hs-vector-space, hs-void, hs-vty, hs-yaml, hs-zlib-bindings, shellcheck, ghc, lhs2tex.
@essandess for port ghc.
@nerdling for port pxsl-tools.

neverpanic · 2019-08-19T15:47:01Z

I think @essandess wanted to switch to builds based on stack, see #4633 and #4698. That would likely make most of our ports for haskell libraries obsolete (which I think is a good thing).

We might then eventually drop haskell-platform completely.

essandess · 2019-08-19T17:02:55Z

@amake Perhaps these modules will all compile with the latest ghc 8.6.5, but the great majority (perhaps all) are years out of date. For example, the MacPorts hs-crypto-api version 12.2 is six years out of date.

As @neverpanic points out, just use Haskell development tools cabal (#4715) or stack (#4633), which will take care of downloading whatever ghc and Haskell code versions are specified in cabal.yaml or stack.yaml.

It’s completely unnecessary and counterproductive to use MacPorts as a package manager for a package manager.

I can envision scenarios where some of these ports would be convenient to download for specific projects, but in general just let cabal and stack take care of it.

macportsbot · 2019-08-19T20:52:14Z

Travis Build #7780 Errored.

Lint results

--->  Verifying Portfile for darcs
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for haskell-platform
Error: Line 91 repeats inclusion of PortGroup haskellplatform
--->  1 errors and 0 warnings found.
--->  Verifying Portfile for hs-aeson
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-asn1-data
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-asn1-types
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-base-unicode-symbols
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-base64-bytestring
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-bibutils
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-blaze-builder
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-blaze-html
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-blaze-markup
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-bloomfilter
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-boolean
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-byteable
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-bytestring-csv
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-bytestring-lexing
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-c2hs
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cereal
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-certificate
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-chunks
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cipher-aes
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cipher-rc4
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-citeproc
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-conduit
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-connection
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cookie
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cpphs
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cprng-aes
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-api
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-cipher-types
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-numbers
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-pubkey-types
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-pubkey
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto-random
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-crypto
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-cryptohash
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-curl
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-accessor-template
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-accessor
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default-class
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default-instances-base
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default-instances-containers
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default-instances-dlist
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default-instances-old-locale
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-data-default
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-dataenc
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-deepseq-generics
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-derive
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-diff
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-digest
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-dlist
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-download-curl
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-edisonapi
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-edisoncore
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-edit-distance
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-enclosed-exceptions
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-entropy
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-exceptions
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-extensible-exceptions
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-failure
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-fclabels
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-feed
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-fingertree
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hashed-storage
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-haskeline
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-haskell-src-exts
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-highlighting-kate
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hinstaller
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hoc
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hs3
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hslogger
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hslua
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-http-client-conduit
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-http-client-tls
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-http-client
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-http-conduit
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-http-types
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hxt-charproperties
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hxt-regex-xmlschema
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hxt-unicode
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-hxt
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-ifelse
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-ipatch
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-json
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-juicypixels
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-lifted-base
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-memotrie
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-missingh
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-mmap
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-mmorph
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-monad-control
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-nats
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-numinstances
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-pandoc-types
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-parsedate
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-pcre-light
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-pem
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-pointedlist
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-polyparse
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-publicsuffixlist
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-puremd5
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-readline
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-regex-tdfa
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-resourcet
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-rosezipper
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-securemem
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-semigroups
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-sha
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-socks
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-storable-complex
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-string-qq
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tagged
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tagsoup-0.12
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tagsoup
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tar
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-temporary
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-terminfo
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-texmath
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tls-extra
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-tls
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-transformers-base
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-type-level
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-uniplate
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-utf8-string
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-utility-ht
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-vector-space
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-void
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-vty
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-xml
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-yaml
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-zip-archive
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hs-zlib-bindings
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for shellcheck
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for hedgewars
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for gf
Warning: no license set
--->  0 errors and 1 warnings found.
--->  Verifying Portfile for ghc
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for lhs2tex
Error: Portfile parent directory textproc does not match primary category devel
--->  1 errors and 0 warnings found.
--->  Verifying Portfile for pandoc
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for pxsl-tools
--->  0 errors and 0 warnings found.

Port darcs's dependencies fail on xcode9.4. Log
Port hs-hashable's dependencies fail on xcode9.4. Log
Port darcs's dependencies fail on xcode8.3. Log
Port hs-hashable's dependencies fail on xcode8.3. Log

The build timed out.

amake · 2019-08-24T12:53:55Z

It’s completely unnecessary and counterproductive to use MacPorts as a package manager for a package manager.

I agree completely. However the fact is that your update to ghc broke a whole bunch of stuff, and

it seems like nothing is being done about that, and
your suggested solutions (stack, cabal) are not available, and
even when they become available (when?), everything will still be broken until each port is fixed

At the very least there could have been an effort to keep existing ports working: make the old ghc portfile available as e.g. "ghc7" and set the haskell portgroup to use that.

I may give up on this PR and look into that (a ghc7 port) instead.

essandess · 2019-08-24T19:08:00Z

update to ghc broke a whole bunch of stuff … it seems like nothing is being done about that … suggested solutions (stack, cabal) are not available … even when they become available (when?), everything will still be broken until each port is fixed … I may give up on this PR and look into that (a ghc7 port) instead.

Comments:

The reason the MacPorts Haskell stack is years out of date is because Haskell builds are very fragile and dependent upon specific compiler and module versions (that’s why cabal and stack were developed). It’s easy to find examples of MacPorts people trying and giving up trying to update ghc along with all those hs-* ports.
Even if you get a ghc7 working, it will almost certainly break on the next update of an hs-* dependency, and no one will bother or be able to update anything in Haskell ports because it’s too fragile and difficult. If you have the cycles for this you’re welcome to try, but this model has already been shown not to work over time, but in Haskell world and in MacPorts. If you need ghc7, it’s much, much more robust and sane to tell stack to use it with the appropriate lts-* resolver.
Anything that breaks because its compiler was updated is itself broken—not the compiler.
The solution to all this is simple: use cabal and stack. These PRs exist, work robustly, and are ready to merge. You can use the Portfiles yourself locally if you need them.
I don’t know what the hold up is. I can only suggest opening an issue or requesting that the MacPorts team drive a decision so that they can be used to fix and build other Haskell-dependent ports.

essandess · 2019-08-24T19:17:33Z

@pmetzger @neverpanic @mf2k @mojca @cjones051073

Would one of you please drive a decision getting stack PR #4633 and cabal PR #4715 merged?

It was predicable and predicted that Haskell-dependent ports would break without these modern Haskell development tools after ghc was updated. Many existing Haskell ports are broken and years out of date and need moderns tools to fix them.

amake · 2019-08-25T12:53:34Z

Even if you get a ghc7 working,

I'm talking about restoring the version of the portfile previous to your update. It was working. And I'm not talking about maintaining it: I would mark it obsolete and it would only exist to fix the current breakage while application ports (as opposed to hs-* library ports) move to stack or whatever.

If you need ghc7, it’s much, much more robust and sane to tell stack

It's not a matter of what's better; it's a matter of keeping the existing MacPorts Haskell world working while we transition to the new way of doing things.

Anything that breaks because its compiler was updated is itself broken—not the compiler.

You might think so, but because the compiled files are stored in a versioned directory (ghc-x.y.z), until someone revbumps every affected port literally everything is broken. All binary builds of everything Haskell currently installs into ${prefix}/lib/ghc-7.8.3 while the new ghc only looks at ${prefix}/lib/ghc-8.6.5.

The solution to all this is simple: use cabal and stack. These PRs exist, work robustly, and are ready to merge. You can use the Portfiles yourself locally if you need them.

This is not acceptable when things that were working just days ago now don't. Even if "use this unmerged portfile" was reasonable (it's not), end users have no way of even knowing about these things without crawling through PRs on GitHub.

If it seems like I'm annoyed by all this, then yes, I am: comments in the ghc port made it clear that updating ghc had huge implications for the entire MacPorts Haskell world, yet they were entirely ignored and now there's a ton of breakage. But I should also say that something absolutely needed to be done about the status quo by someone knowledgeable, so thank you @essandess for bringing your expertise to bear and for all your hard work in this area.

essandess · 2019-08-25T19:44:42Z

@amake

It's not a matter of what's better; it's a matter of keeping the existing MacPorts Haskell world working while we transition to the new way of doing things.

I honestly don't believe that's possible given both the fragility of Haskell world tools and the half-decade+ age of the existing MacPorts versions. The entire MacPorts Haskell world is a house of cards—that's why no one touched it for so long.

I get the frustration, but really a six-year-old version of a package under active development can't considered to be "working" anymore. The most efficient path forward is to use modern Haskell development tools to fix what needs fixing, and if those aren't available or working yet, please open a ticket at https://trac.macports.org.

neverpanic · 2019-09-12T22:50:06Z

* [x]  darcs: #5192
* [x]  gf: #5190
* [x]  lhs2tex: #5195
* [x]  pxsl-tools: #5183
So once these can be moved to haskell_stack, we can remove all hs-* ports and haskell-platform? And by remove, I mean we delete the ports entirely?

With those ports merged now and #5264 around the corner, should we now continue to remove the rest of the ports? I'm not sure going through the obsoleting process makes sense for those, since we don't have a replacement, so I'd in fact just outright delete them.

Should we also look at DoCon, HaXml, distract and hedgewars? Those don't seem that important to me, thuogh…

kencu · 2019-09-13T18:36:41Z

In the hedgewars port, haskell is used to build only the server component. So I think just that part can be disabled until such time as I see if it works with the new stack-based layout.

essandess · 2019-09-13T22:08:49Z

@cjones051073

Here's a MacPorts puzzle for you.

I'd like to simplify the stack Portfile so that it self-referentially builds with the haskell_stack portgroup.

The haskell_stack portgroup adds port:stack as a build dependency.

No problem, I thought, I'll simply delete it in the refactored Portfile like this:

depends_build-delete \
                port:stack

But port -s install stack still trys to install stack first and I'm still seeing this:

port deps stack
Full Name: stack @2.1.3_1
Build Dependencies:   stack

Shouldn't that simply work without modding the portgroup? Any idea why I can't edit out a build dependency?

neverpanic · 2019-09-14T17:01:04Z

No problem, I thought, I'll simply delete it in the refactored Portfile like this:
depends_build-delete \
                port:stack

By the time you delete the stack dependency, it isn't in the list yet. This is due to the PortGroup's use of port::register_callback, which allows PortGroups to register a callback that gets executed when the rest of the Portfile was run. In the case of this PortGroup, the registered callback adds the dependencies. The rationale for using this method is that you can't accidentally forget to add the stack dependency, e.g. by using depends_build port:somethingelse in the Portfile, and that you only get the GHC dependency when haskell_stack.system_ghc is yes (and you don't need complicated logic to add it to depends_build when haskell_stack.system_ghc is set to yes and remove it again when it gets set to no).

Shouldn't that simply work without modding the portgroup? Any idea why I can't edit out a build dependency?

In this case (and others where we have done the same thing), just add an if in the PortGroup so that it doesn't add the dependency if $subport eq "stack", because it just doesn't make sense to add a self-dependency.

cjones051073 · 2019-09-14T17:08:56Z

No problem, I thought, I'll simply delete it in the refactored Portfile like this:
depends_build-delete \
                port:stack
By the time you delete the stack dependency, it isn't in the list yet. This is due to the PortGroup's use of port::register_callback, which allows PortGroups to register a callback that gets executed when the rest of the Portfile was run. In the case of this PortGroup, the registered callback adds the dependencies. The rationale for using this method is that you can't accidentally forget to add the stack dependency, e.g. by using depends_build port:somethingelse in the Portfile, and that you only get the GHC dependency when haskell_stack.system_ghc is yes (and you don't need complicated logic to add it to depends_build when haskell_stack.system_ghc is set to yes and remove it again when it gets set to no).

Generally speaking, its always better to use depends_build-append etc. In portfiles, to avoid this sort if problem, implicitly removing dependencies added by portgroups.

Shouldn't that simply work without modding the portgroup? Any idea why I can't edit out a build dependency?

In this case (and others where we have done the same thing), just add an if in the PortGroup so that it doesn't add the dependency if $subport eq "stack", because it just doesn't make sense to add a self-dependency.

cjones051073 · 2019-09-14T17:11:41Z

@amake can you please address the conflicts?

essandess · 2019-09-14T19:00:56Z

the PortGroup's use of port::register_callback, which allows PortGroups to register a callback that gets executed when the rest of the Portfile was run.

Oh I see now. I was scratching my head about your suggestion above to use ${name} because I though that wouldn't be defined yet.

I have a refactor ready to go, but I don't know how to do a local test with a modified portgroup, so I'll just kick it into an azure build and see what happens.

cjones051073 · 2019-09-14T19:20:12Z

the PortGroup's use of port::register_callback, which allows PortGroups to register a callback that gets executed when the rest of the Portfile was run.

Oh I see now. I was scratching my head about your suggestion above to use ${name} because I though that wouldn't be defined yet.

I have a refactor ready to go, but I don't know how to do a local test with a modified portgroup, so I'll just kick it into an azure build and see what happens.

That is easy. Just configure macports to use your ports checkout as its primary source. Then whatever you change in that checkout is what is used.

essandess · 2019-09-14T19:23:30Z

That is easy. Just configure macports to use your ports checkout as its primary source. Then whatever you change in that checkout is what is used.

🤷🏼‍♂️🤷🏼‍♂️🤷🏼‍♂️🧐

Easier:

sudo vi /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/haskell_stack-1.0.tcl

cjones051073 · 2019-09-14T19:27:13Z

That is easy. Just configure macports to use your ports checkout as its primary source. Then whatever you change in that checkout is what is used.

🤷🏼‍♂️🤷🏼‍♂️🤷🏼‍♂️🧐

Easier:
sudo vi /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/haskell_stack-1.0.tcl

Thats far from ideal as running port sync will just over write whatever you do there. Also using sudo just to edit is unpleasant.

Just follow

https://trac.macports.org/wiki/howto/SyncingWithGit

essandess · 2019-09-14T19:30:51Z

That is easy. Just configure macports to use your ports checkout as its primary source. Then whatever you change in that checkout is what is used.

🤷🏼‍♂️🤷🏼‍♂️🤷🏼‍♂️🧐
Easier:
sudo vi /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/haskell_stack-1.0.tcl
Thats far from idea as run port sync will just over write whatever you do there. Also using sudo just to edit is unpleasant.

I just need a 3 second debug before throwing this over the wall to azure.

How do I write the portgroup to detect that I'm calling it from the port stack? This code throws an error:

proc haskell_stack.add_dependencies {} {
    if {${name} ne "stack"} { 
        depends_build-append port:stack
    } 
    if {[option haskell_stack.system_ghc]} {
        depends_build-append port:ghc
    }
}

Badness on a local Portfile of stack:

$ sudo port clean --all stack
Error: Unable to open port: can't read "name": no such variable

cjones051073 · 2019-09-14T19:33:56Z

That is easy. Just configure macports to use your ports checkout as its primary source. Then whatever you change in that checkout is what is used.

🤷🏼‍♂️🤷🏼‍♂️🤷🏼‍♂️🧐
Easier:
sudo vi /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/haskell_stack-1.0.tcl
Thats far from idea as run port sync will just over write whatever you do there. Also using sudo just to edit is unpleasant.
I just need a 3 second debug before throwing this over the wall to azure.

How do I write the portgroup to detect that I'm calling it from the port stack? This code throws an error:
proc haskell_stack.add_dependencies {} {
    if {${name} ne "stack"} { 
        depends_build-append port:stack
    } 
    if {[option haskell_stack.system_ghc]} {
        depends_build-append port:ghc
    }
}
Badness on a local Portfile of stack:
$ sudo port clean --all stack
Error: Unable to open port: can't read "name": no such variable

You need to define the fact you are using a global variable. Add

global name

In the callback before using it.

essandess · 2019-09-14T19:37:29Z

You need to define the fact you are using a global variable. Add

global name

In the callback before using it.

Thanks, using {${name}} appears to be working too, which looks like it prevents variable expansion until the register_callback when name is actually defined. Isn't that what I want?

Otherwise, name wouldn't be set to stack yet, right?

essandess · 2019-09-14T19:38:15Z

This code:

proc haskell_stack.add_dependencies {} {
    if { {${name}} ne "stack" } {
        depends_build-append port:stack
    }
…

cjones051073 · 2019-09-14T19:45:13Z

You need to define the fact you are using a global variable. Add
global name
In the callback before using it.

Thanks, using {${name}} appears to be working too, which looks like it prevents variable expansion until the register_callback when name is actually defined. Isn't that what I want?

Otherwise, name wouldn't be set to stack yet, right?

I don’t know enough tcl to comment. All i can say is if you check other PGs doing similar things, they use the global declarations for used variables. So if that works i would do the same.

If you want more clarification, best asking on the devel list for someone with more tcl experience to comment.

essandess · 2019-09-14T19:45:40Z

@cjones051073 @neverpanic

Separate MacPorts question for the stack self-referencing Portfile.

I need to make sure that ${worksrcpath} points to the downloaded source code, and that I can just grab the prebuilt binary from some other directory. This code isn't working to mirror the files I need.

How do I tell MacPorts grab this distfile from this location, and this other distfile from this other location?

Not-working Portfile code:

master_sites        \
                    ${github.homepage}/archive \
                    ${github.homepage}/releases/download/v${github.version}

distname            ${name}-${github.version}-osx-x86_64

distfiles           \
                    v${github.version}${extract.suffix} \
                    ${distname}${extract.suffix}

essandess · 2019-09-14T22:49:02Z

if you check other PGs doing similar things, they use the global declarations for used variables. So if that works i would do the same.

As usual @cjones051073 is right. See PR #5275.

essandess · 2019-09-16T09:48:54Z

So once these can be moved to haskell_stack, we can remove all hs-* ports and haskell-platform? And by remove, I mean we delete the ports entirely?

With those ports merged now and #5264 around the corner, should we now continue to remove the rest of the ports? I'm not sure going through the obsoleting process makes sense for those, since we don't have a replacement, so I'd in fact just outright delete them.

I've been copy-and-pasting descriptions and the like from the existing hs-* ports. I think it's too early to delete these because they'll still be useful as references as we modernize the Haskell stack.

See what was necessary to pull in pieces of the missing Haskell Platform (alex, happy, HsColour) in PR #5272 for ghc.

Ultimately, all the things in Haskell Platform should probably be organized as supports in a Haskell_platform port that consistent with its namesake, but with modernized/robust build recipes.

neverpanic · 2019-09-16T12:34:38Z

I've been copy-and-pasting descriptions and the like from the existing hs-* ports. I think it's too early to delete these because they'll still be useful as references as we modernize the Haskell stack.

The descriptions are verbatim copies from hackage.haskell.org. Also, deleting these ports doesn't mean they will be gone from the git history.

essandess · 2019-09-17T12:46:30Z

deleting these ports doesn't mean they will be gone from the git history.

Sounds good.

amake · 2019-10-04T13:22:19Z

@amake can you please address the conflicts?

I'm going to discard the PR in its current state and instead remove all hs-* ports once I've dealt with DoCon, HaXml, distract and hedgewars.

I investigated DoCon, and even the newest version (2.12 from 2014) is simply too old to be built with stack, cabal, or current ghc. So I think we may just have to abandon that one. Now to look at the others...

amake · 2019-10-06T14:09:35Z

I've updated HaXml.

distract is too old (I tried both cabal and stack)
hedgewars is too complicated: even without building the server component, we are using Haskell instead of fpc for some core Pascal components, and I just couldn't get it to work. Maybe we could switch to fpc but it claims to need a prerelease version, which would mean adding an fpc-devel subport and I haven't looked into that.

Then there are some more ports I noticed are likely affected:

thrift (+haskell variant)
buddha
pure-gen

My appetite for this is waning rapidly.

kencu · 2019-10-06T15:34:19Z

I can look into fixing hedgewars if it's fixable; I have the fpc version of hedgewars here in a repo. Please leave it with me.

kencu · 2020-04-17T03:24:40Z

I'm looking to kill off ancient PRs that aren't going anywhere -- is this one?

amake · 2020-04-17T03:25:55Z

Yeah I'm not working on it anymore. I'll close it.

essandess · 2020-04-17T11:07:13Z

Note that there remains of ton of dead or obsolete Haskell ports: ghc-bootstrap, haskell-platform, hs-*, groups haskell-1.0 and haskell-2.0, and more.

https://github.com/macports/macports-ports/search?p=1&q=haskell&unscoped_q=haskell

neverpanic · 2020-04-17T14:08:06Z

We should probably just delete those, unless somebody objects?

nickgaya · 2020-10-04T04:27:02Z

Any progress on cleaning up obsolete ports? See comments on https://trac.macports.org/ticket/61263

amake added 10 commits August 19, 2019 22:03

ghc: restore important instructions for updating

1a812a2

haskell PortGroup: bump ghc version to 8.6.5

8f402eb

Haskell ports: bump revision due to GHC update

493abe1

grep -lR 'PortGroup.*haskell' . | xargs -n 1 sh -c "awk '/revision/{sub(/[[:digit:]]+/,\$NF+1)}1' \$0 > \$0.new; mv \$0.new \$0"

haskell-platform: fix livecheck

9c7acef

The version has been removed from the homepage, so use GitHub instead.

haskell-platform: update to 8.6.5

dec0d44

haskell-platform: hs-stm is supplied by ghc

39a4fd1

haskell-platform: hs-mtl is supplied by ghc

420edaf

haskell-platform: hs-parsec is supplied by ghc

39f008e

haskell-platform: hs-text is supplied by ghc

4fc9afc

haskell-platform: hs-scientific is supplied by haskell-platform

46c5c90

TODO: Figure out how to handle lost epoch (subports don't allow epoch?)

amake added the wip Work in progress label Aug 19, 2019

macportsbot assigned neverpanic and nerdling Aug 19, 2019

macportsbot added by: member Created by a member with commit rights maintainer: open Affects an openmaintainer port type: bugfix labels Aug 19, 2019

amake mentioned this pull request Aug 19, 2019

cabal: Submission of Haskell Cabal: Common Architecture for Building App… #4715

Merged

12 tasks

[WIP] haskell-platform: libs through attoparsec now building

bb13a10

amake force-pushed the haskell branch from 78ed591 to bb13a10 Compare August 19, 2019 15:43

neverpanic removed their assignment Aug 19, 2019

amake mentioned this pull request Aug 24, 2019

pandoc: Update to 2.7.3 with major Portfile refactoring #4698

Merged

12 tasks

essandess mentioned this pull request Sep 7, 2019

Configuring extra-lib-dirs in stack.yaml to build on macOS IHaskell/IHaskell#1081

Closed

amake closed this Apr 17, 2020

[WIP] Fix broken Haskell world #5050

[WIP] Fix broken Haskell world #5050

Conversation

amake commented Aug 19, 2019 • edited Loading

Description

Type(s)

Tested on

Verification

macportsbot commented Aug 19, 2019

neverpanic commented Aug 19, 2019

essandess commented Aug 19, 2019

macportsbot commented Aug 19, 2019

amake commented Aug 24, 2019

essandess commented Aug 24, 2019

essandess commented Aug 24, 2019 • edited Loading

amake commented Aug 25, 2019 • edited Loading

essandess commented Aug 25, 2019

neverpanic commented Sep 12, 2019

kencu commented Sep 13, 2019

essandess commented Sep 13, 2019 • edited Loading

neverpanic commented Sep 14, 2019

cjones051073 commented Sep 14, 2019

cjones051073 commented Sep 14, 2019

essandess commented Sep 14, 2019

cjones051073 commented Sep 14, 2019 • edited Loading

essandess commented Sep 14, 2019

cjones051073 commented Sep 14, 2019 • edited Loading

essandess commented Sep 14, 2019

cjones051073 commented Sep 14, 2019

essandess commented Sep 14, 2019

essandess commented Sep 14, 2019

cjones051073 commented Sep 14, 2019

essandess commented Sep 14, 2019 • edited Loading

essandess commented Sep 14, 2019

essandess commented Sep 16, 2019

neverpanic commented Sep 16, 2019

essandess commented Sep 17, 2019

amake commented Oct 4, 2019

amake commented Oct 6, 2019

kencu commented Oct 6, 2019

kencu commented Apr 17, 2020

amake commented Apr 17, 2020

essandess commented Apr 17, 2020

neverpanic commented Apr 17, 2020

nickgaya commented Oct 4, 2020

amake commented Aug 19, 2019 •

edited

Loading

essandess commented Aug 24, 2019 •

edited

Loading

amake commented Aug 25, 2019 •

edited

Loading

essandess commented Sep 13, 2019 •

edited

Loading

cjones051073 commented Sep 14, 2019 •

edited

Loading

cjones051073 commented Sep 14, 2019 •

edited

Loading

essandess commented Sep 14, 2019 •

edited

Loading