| 25 May 2021 |
 srid | Anyone fancy trying some Haskell stuff here?
Utilizing the power of Nix, every repl comes preloaded with over 30,000 packages. Adding a package is as simple as adding it as a dependency in the replit.nix file. https://lobste.rs/s/dy4x1c/how_we_went_from_supporting_50_languages
| 16:19:11 |
|  zwro changed their display name from z to yin. | 18:05:13 |
 utdemir | srid: seems to work as expected https://replit.com/@utdemir/nix-hs . My first impressions:
- There's not much magic going on, they pretty much only installed Nix with a mounted /nix/store.
- Run command simply runs
nix-shell .. --run '..', so I guess when the Nix expression becomes larger it'd be annoying to wait for Nix evaluation every time you run something.
| 23:46:14 |
| 26 May 2021 |
 cdepillabout | maralorn sterni (he/him) For haskell-updates, it looks like everything in maintained and mergeable is now building (or correctly marked broken). We have the choice of merging haskell-updates into master now (only after of course checking that merging would cause no eval errors), or merging master into haskell-updates and waiting for Hydra to work through all the builds again. | 01:44:31 |
| cdepillabout | I'm leaning towards merging haskell-updates into master. But I don't really have a good idea of how risky it is, or what peti would normally do. | 01:45:50 |
| cdepillabout | * I'm leaning towards merging haskell-updates into master. But I don't really have a good idea of how risky it is, or what peti would normally do. Do either of you guys have an opinion here? | 01:46:29 |
 bqv | > Other idea btw: we can theoretically find packages requiring a jail break algorithmically. We could us that to a) mark them broken before they even failed once and b) mark them automatically unbroken as soon as they build again. So a temp incompatibility like now with random will not disable a package permanently.
PLEASE fucking do it | 03:33:52 |
| bqv | This shit's a plague | 03:33:58 |
|  ashleyis joined the room. | 03:59:11 |
 joe (he/him) | I wonder what would happen if only breaking changes which don't change types required a major version bump... | 04:23:51 |
| joe (he/him) | obviously it's no good for build planning | 04:24:05 |
| joe (he/him) | Or similarly: If a package needs to be jailbroken, don't "just do it" if the types haven't changed | 04:24:56 |
 berberman | Hi, haskell-language-server recently upgrades apply-refact to 0.9.3.0, which was released 2021-05-21, but it seems that haskell-updates does not have this new version yet. When will haskell-updates update? Will "Haskell updates #123682" include this? | 05:46:08 |
 maralorn | In reply to @cdepillabout:matrix.org
I'm leaning towards merging haskell-updates into master. But I don't really have a good idea of how risky it is, or what peti would normally do. Do either of you guys have an opinion here? From all I can tell peti never gave a frack about rebuilds. Just merge it.^^ | 08:52:34 |
| maralorn | In reply to @_xmpp_qy=40xa0.uk:matrix.org
This shit's a plague Can you elaborate what exactly annoys you most? | 08:53:53 |
|  fabfianda changed their display name from Fab to fabfianda. | 09:01:07 |
| maralorn | The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated. | 09:01:35 |
| maralorn | In reply to @berberman:mozilla.org
Hi, haskell-language-server recently upgrades apply-refact to 0.9.3.0, which was released 2021-05-21, but it seems that haskell-updates does not have this new version yet. When will haskell-updates update? Will "Haskell updates #123682" include this? No, I don‘t think so. We do an update roughly every 2 weeks. | 09:02:53 |
| maralorn | berberman: Here is a description of our current progress: https://github.com/NixOS/nixpkgs/issues/121140#issuecomment-830816599 | 09:08:02 |
| maralorn | * berberman: Here is a description of our current process: https://github.com/NixOS/nixpkgs/issues/121140#issuecomment-830816599 | 09:08:19 |
| maralorn | cdepillabout: Your PRs currently reference the HACKING.md which does not yet exist in the repo. | 09:08:39 |
| berberman | maralorn: I see, thank you! | 09:09:11 |
| joe (he/him) | Thanks for keeping Haskell+Nix so great! | 09:21:05 |
| joe (he/him) | There should be a pizza/beer fund to be used by the person doing the merge every period | 09:28:31 |
|  immae (he/him) changed their display name from immae to immae (he/him). | 10:13:07 |
 sterni (he/him) | In reply to @maralorn:maralorn.de
From all I can tell peti never gave a frack about rebuilds. Just merge it.^^ ideally you would merge master into haskell-updates once again wait fro the rebuilds to finish and merge then | 12:39:53 |
| sterni (he/him) | which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent) | 12:40:14 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated. also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) | 12:41:21 |
| maralorn | In reply to @sternenseemann:systemli.org
also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) I am not really afraid of that. Yes, automation brings complexity but if done well complexity covered by the code is complexity we developers don't need to deal with. | 12:57:56 |
| sterni (he/him) | It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing | 12:59:23 |
