Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix build with text 2.1.2 #752

Merged
merged 1 commit into from
Nov 1, 2024
Merged

Fix build with text 2.1.2 #752

merged 1 commit into from
Nov 1, 2024

Conversation

georgefst
Copy link
Contributor

https://hackage.haskell.org/package/text-2.1.2/changelog

We need to deal with show now being exported from Data.Text.

Strictly speaking, all old versions of Miso need a Hackage revision setting text < 2.1.2.

@dmjio dmjio merged commit 9d15de0 into dmjio:master Nov 1, 2024
3 checks passed
georgefst added a commit to georgefst/ghc-wasm-miso-examples that referenced this pull request Nov 27, 2024
All previous versions are broken, especially without Hackage revisions to add bounds: dmjio/miso#752.
@georgefst
Copy link
Contributor Author

georgefst commented Dec 24, 2024

@dmjio Could I nudge you for a release and revisions here? I keep hitting build errors in all of my projects because of the lax bounds. And thus having to manually constrain Cabal to pick an older text, or else vendoring Miso via source-repository-package.

@dmjio
Copy link
Owner

dmjio commented Feb 9, 2025

Coming back to this, I think the better solution would be to not re-export show from Miso.String, as opposed to hiding explicitly in all imports. text also ships as a boot package w/ GHC and its not overrideable w/ nix haskell builds.

{-# LANGUAGE CPP #-}

module Miso.String ( module X ) where

#if MIN_VERSION_text(2,1,2)
import qualified Data.Text as X hiding (show)
#else
import qualified Data.Text as X
#endif 

dmjio added a commit that referenced this pull request Feb 9, 2025
dmjio added a commit that referenced this pull request Feb 9, 2025
* Hide `show` re-exports on text > 2.1.2 in Miso.String

* Revert "Fix build with `text` 2.1.2 (#752)"

This reverts commit 9d15de0.

* Use explicit Prelude
@georgefst
Copy link
Contributor Author

Coming back to this, I think the better solution would be to not re-export show from Miso.String, as opposed to hiding explicitly in all imports.

Yes, much better idea! I can't remember why I did it my way to be honest.

I will say again, Hackage revisions for old versions would be useful in order to prevent bad build plans. This is quite easy to do with hackage-cli.

@dmjio
Copy link
Owner

dmjio commented Feb 11, 2025

It should be fine now that the CPP is in. Regarding build plans, they aren't necessary if nix is used as your resolver. Nix is unfortunately still necessary for reasonably working with GHC cross compilers. It also keeps us from playing "package bumper" all the time. The external APIs for most of miso's deps. don't change, like text. Nobody is changing pack for example.

@georgefst
Copy link
Contributor Author

Nix is unfortunately still necessary for reasonably working with GHC cross compilers.

This isn't really true for the Wasm backend. And even when using Nix there, the common approach is to use the ghc-wasm-meta flake, which means using Nix to get hold of an appropriately compiled and wrapped GHC and Cabal, but not using Nix as the resolver.

Anyway, I can't force you to do it! And I'm aware that there's some PvP skepticism among Nix and Stack users. I will just have to keep a mental note that not using the latest version of Miso might result in build failures.

@dmjio
Copy link
Owner

dmjio commented Feb 11, 2025

So far there's been no build failures reported by users until text (mostly heavily used package in the ecosystem) changed its external API. Ideally we can integrate GHC WASM into nixpkgs correctly so that it can take advantage of cached packages. Not sure this is feasible though because it uses a non-upstreamable fork of LLVM.

@dmjio
Copy link
Owner

dmjio commented Feb 12, 2025

If it starts getting out of hand I'll add constraints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants