17 Oct 2024 |
toonn | *preserving | 15:52:58 |
fgaz | In reply to @sternenseemann:systemli.org I think bound management can become easy if someone sits down and writes a little bit of tooling, basically you just need to get notified about releases in your dependencies and then be provided with a install plan to easily test the new possibility the first part is already there. you can enable notifications in hackage settings | 16:08:39 |
sterni | neat! | 16:08:51 |
sterni | In reply to @maralorn:maralorn.de I mean nomeata automated a significant chunk of that with the cabal bounds stuff. that was the literal opposite solution of what I had in mind though | 16:09:08 |
sterni | iirc it just takes the current plan and converts it into PVP bounds a priori, so they are probably too tight | 16:09:37 |
sterni | * iirc it just takes the current plan and converts it into PVP bounds a priori, so they are probably too tight in practice | 16:09:46 |
| @sammy:cherrykitten.dev left the room. | 18:24:53 |
18 Oct 2024 |
chreekat | https://hackage.haskell.org/upload#versioning_and_curation regarding the x-curation field | 08:31:02 |
emily | hmm, what is the purpose of Hackage offering to host packages that are explicitly opting out of playing well with the ecosystem…? | 08:33:11 |
emily | I remember controversy over metadata revisions but not that it had reached this point | 08:33:18 |
chreekat | as best I can tell, it was a compromise made at the height of the controversy. Packages lacking bounds already existed, then revisions started happening, some people wanted to be able to opt out | 08:34:27 |
emily | yeah. seems reasonable to say that if you want your code on Hackage then you have to play nice, but I do remember fights about it. | 08:35:15 |
emily | I wonder if any package actually sets the "don't email me" value 😅 | 08:35:34 |
chreekat | In reply to @sternenseemann:systemli.org I think bound management can become easy if someone sits down and writes a little bit of tooling, basically you just need to get notified about releases in your dependencies and then be provided with a install plan to easily test the new possibility this has existed for a long time. It's Stackage. :) | 08:36:27 |
chreekat | In reply to @emilazy:matrix.org I wonder if any package actually sets the "don't email me" value 😅 lol yeah. I find it funny that the setting doesn't seem to opt you out of curation at all. It just lets you stop getting emails about it... | 08:36:58 |
emily | I think it's implicit in saying that it's a variant of uncurated , which "choose[s] to exclude individual package uploads from curation" | 08:37:34 |
chreekat | But then it also says, " Trustees or maintainers may adopt uncurated packages into the curated layer through metadata revisions. " | 08:39:03 |
chreekat | to be fair I don't really understand what that means | 08:40:05 |
emily | oh, true indeed. and then wtf does uncurated-seeking-adoption mean given that | 08:40:50 |
emily | classic political compromise I guess | 08:41:07 |
chreekat | with a hint of passive aggressiveness | 08:41:17 |
emily | I'm going to assume 3 really angry people used this functionality religiously for a year and nobody else ever has | 08:41:17 |
chreekat | lol yeah | 08:41:31 |
chreekat | I remember at the time there was talk about having hackage "overlays". I actually thought it was kind of a neat idea. Stackage could be an overlay. But the "curated Hackage" could also be an overlay -- rather than the assumed default | 08:45:37 |
chreekat | Just idle talk at this point | 08:46:37 |
sterni | In reply to @b:chreekat.net this has existed for a long time. It's Stackage. :) idk I use stackage in the way it shouldn't i have too loose bounds and try to fix build errors when they occur in stackage instead of bit by bit loosening them :p | 09:23:50 |
sterni | Alex: figured out 8.10.7 riscv64 cross :) | 09:24:42 |
fgaz | I'm trying to build a project that depends on ghcjs-base with the js backend. I put ghcjs-base in executableHaskellDepends and called the package with pkgsCross.ghcjs.haskell.packages.ghc98.callPackage . However, the derivation contains no reference to ghcjs-base and the build fails with "Encountered missing or private dependencies: ghcjs-base". Is this a known issue? I couldn't find any nixpkgs ticket about this. | 12:20:50 |
fgaz | I just tried to build some packages that depend on ghcjs-base (for example pkgsCross.ghcjs.haskell.packages.ghc98.ghcjs-promise ) and they all have the same issue. | 12:24:03 |
fgaz | Apparently pkgsCross.ghcjs.haskell.packages.ghc98.ghcjs-base is null , despite it being defined in hackage-packages.nix | 12:31:38 |