Newest at the top
| 2025-04-25 15:04:30 +0200 | <ii8> | Alright, I'll try that then, thanks |
| 2025-04-25 15:01:57 +0200 | <haskellbridge> | <ozkutuk> I guess pinning index-state would be enough then |
| 2025-04-25 15:01:45 +0200 | <ii8> | s/considend/consistent |
| 2025-04-25 15:01:24 +0200 | tromp | (~textual@2001:1c00:3487:1b00:c44:d27d:c88:929f) |
| 2025-04-25 15:01:19 +0200 | <ii8> | merijn: In that case it would be fine, I'm assuming a consistend build environment |
| 2025-04-25 15:01:01 +0200 | <haskellbridge> | <ozkutuk> or a package could depend on, say, "unix" package if the OS is linux and "Win32" if its windows |
| 2025-04-25 14:59:55 +0200 | haritz | (~hrtz@user/haritz) haritz |
| 2025-04-25 14:59:55 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000::2) (Changing host) |
| 2025-04-25 14:59:55 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000::2) |
| 2025-04-25 14:59:53 +0200 | <merijn> | ii8: Could be a flag that detects whether C library X is on the system and use that if it is |
| 2025-04-25 14:59:25 +0200 | <ii8> | If the index-state is fixed and I'm building from the same source tarball, can the flags still end up different? |
| 2025-04-25 14:58:52 +0200 | <ii8> | I'm not sure what that means |
| 2025-04-25 14:58:18 +0200 | <merijn> | ii8: Because they're auto toggle |
| 2025-04-25 14:57:52 +0200 | <ii8> | Why might the flags change? |
| 2025-04-25 14:55:10 +0200 | <haskellbridge> | <ozkutuk> for example, it also records the set package flags for the dependencies |
| 2025-04-25 14:54:56 +0200 | <haskellbridge> | <ozkutuk> ii8: freeze file provides stronger guarantees wrt determinism compared to index-state |
| 2025-04-25 14:54:56 +0200 | <merijn> | ii8: The solver is deterministic, so index-state should be sufficient |
| 2025-04-25 14:54:41 +0200 | <merijn> | ii8: Right, but if you run the build in a dir with a cabal.project file you can force a specific index-state just fine |
| 2025-04-25 14:53:21 +0200 | <ii8> | jackdk: not an option for me I think |
| 2025-04-25 14:52:36 +0200 | <ii8> | I guess assuming it contains an index-state setting. Is that enough or is the freeze file needed too to fix the build? |
| 2025-04-25 14:50:04 +0200 | <ii8> | Are you sure that just a project file existing guarantees that all dependencies are fixed? |
| 2025-04-25 14:48:46 +0200 | ethantwardy | (~user@user/ethantwardy) (Quit: WeeChat 4.4.2) |
| 2025-04-25 14:47:49 +0200 | <ii8> | I just need a way to make sure that cabal always pulls the exact same sources for any given project |
| 2025-04-25 14:47:03 +0200 | <ii8> | merijn: I'm coming from the perspective of packaging haskell programs for linux distros, so I won't be pushing anything to hackage |
| 2025-04-25 14:41:08 +0200 | <haskellbridge> | <Liamzee> postgresql simple, i guess, opaleye |
| 2025-04-25 14:41:01 +0200 | <haskellbridge> | <Liamzee> done already |
| 2025-04-25 14:40:59 +0200 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/hasql-transaction |
| 2025-04-25 14:40:57 +0200 | <haskellbridge> | <Liamzee> also, about PGRef: |
| 2025-04-25 14:40:10 +0200 | <haskellbridge> | <Liamzee> is there a reason to use postgresql simple instead of hasql? |
| 2025-04-25 14:36:08 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-04-25 14:24:35 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-04-25 14:23:26 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-04-25 14:23:08 +0200 | jespada | (~jespada@179.26.245.3) jespada |
| 2025-04-25 14:12:36 +0200 | tv | (~tv@user/tv) tv |
| 2025-04-25 14:11:12 +0200 | <jackdk> | ii8: If that's your goal, I would use Nix |
| 2025-04-25 13:57:22 +0200 | mceresa | (~mceresa@user/mceresa) (Ping timeout: 265 seconds) |
| 2025-04-25 13:55:38 +0200 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-04-25 13:55:38 +0200 | sixfourtwelve | (~ethanmorg@82.18.82.103) sixfourtwelve |
| 2025-04-25 13:54:36 +0200 | <merijn> | but at that point, what have you really accomplished? |
| 2025-04-25 13:54:25 +0200 | <merijn> | I mean, I guess your script could be simply "cabal <cmd> --project-file=<filename>" and that'd fail on a non-existent file |
| 2025-04-25 13:53:40 +0200 | <merijn> | It should use that projectfile by default, but there's no way to force it to fail if missing |
| 2025-04-25 13:53:03 +0200 | <merijn> | Inside a repo you could have a cabal.project file to enforce a specific index-state, though |
| 2025-04-25 13:52:43 +0200 | <merijn> | ii8: Since cabal package are intended to be reusable generally, allowing something like that in a package on Hackage would be a nightmare |
| 2025-04-25 13:52:11 +0200 | <merijn> | ii8: But doing that in a cabal package is antithetical to it's purpose |
| 2025-04-25 13:51:56 +0200 | <merijn> | ii8: I mean, if you have a cabal.project file in the repo you will get that behaviour |
| 2025-04-25 13:49:38 +0200 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2025-04-25 13:47:40 +0200 | <ii8> | It'd be kind of a tricky script I fear. So there's no way to tell cabal I want a build to be reproducible and it shouldn't do any solving or searching? |
| 2025-04-25 13:44:56 +0200 | tromp | (~textual@2001:1c00:3487:1b00:c44:d27d:c88:929f) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-25 13:42:36 +0200 | <merijn> | You could write a script that does that and invoke cabal from there |
| 2025-04-25 13:41:42 +0200 | <merijn> | ii8: Not really, no |