Haskell in Nixpkgs/NixOS | 706 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 142 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Aug 2025 | ||
| I wrote that code when LLVM default was a few versions back, seems like now where it's practically latest we could also sync it with the default version | 20:36:03 | |
| instead of latest available | 20:36:07 | |
| 20:36:52 | ||
| right | 20:36:55 | |
| we should be defaulting to LLVM 21 for 25.11, hopefully | 20:37:39 | |
| 20:40:53 | ||
In reply to @sternenseemann:systemli.orgI took a brief look at the hydra log linked. I only saw logs for three failed jobs and from those one is the text/show issue and another one is too strict upper bound on data-defaylt that was PRed recently but has no progress in merging :-( i pinged them on that PR: https://github.com/dhall-lang/dhall-haskell/pull/2659#issuecomment-3234999428 | 21:37:33 | |
I think adding a data-default == 0.7.1.3 and adding it to the failed packages' override could work, I'm checking on dhall-lsp-server | 21:41:02 | |
| Redacted or Malformed Event | 23:15:20 | |
| it's not enough | 23:15:42 | |
| 29 Aug 2025 | ||
| 02:40:19 | ||
| 07:03:56 | ||
| downgrading data-default is not a good option anyways since it is likely to cause issues elsewhere | 10:41:45 | |
| We can do the bound adjustment via patches/overrides as well, we don't need to wait for upstream | 10:43:00 | |
| Ughh I've had terrible trouble with data-default-class vs data-default. Had to update bounds for another package because of the incompatible update. | 10:58:40 | |
| despite the patches, jailbreaks, I end up with this issue:
is it fine if I patch it as | 11:15:33 | |
In reply to @thibaut:fsl.shThis is a problem with many packages :-( | 11:22:57 | |
| The best solution is probably to submit a proper patch for this to upstream, using CPP. You'd want to use Text.show for text >= 2.1.2 and keep the current code for Text < 2.1.2. | 11:32:49 | |
| Prelude.show would work, I guess, though it is a bit silly to implement tshow yourself if Data.Text exposes it now | 11:33:59 | |
| I don't think you need any CPP: with proper qualifications it should be perfectly backwards compatible. | 13:19:25 | |
| sure | 16:04:05 | |
| * ~~sure~~ | 16:04:30 | |
| * | 16:04:35 | |
| 19:30:45 | ||
all this text's show fallout is due to the fact that in Haskell you can't require people to import qualified. See, certain modules, including Data.Text, are designed to be imported qualified. They will say so in the documentation. But this is only a guideline. It's impossible to enforce. So, anyone who ignored this guideline, imported Data.Text unqualified, and also happened to use show from Prelude, gets blown out... And the good fix is to import Data.Text qualified and update the usages of stuff from there. An easy fix is to update the usages of show to Prelude.show. None if these two are one-line fix in general, sadly. | 19:38:03 | |
| I mean I kinda think importing without import lists or unqualified should be prevented by a linter on hackage upload. | 19:43:05 | |
| sometimes you do want that (modules specifically designed as preludes), no? | 19:43:40 | |
| even in Rust people sometimes do glob imports for that case | 19:43:52 | |
| Yeah, fair. | 19:51:03 | |
| Importing Data.Text unqualified would also not be a problem if people actually stuck to the PVP. | 19:52:10 | |