Newest at the top
| 2026-02-05 22:13:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-05 22:13:38 +0100 | <tomsmeding> | if he's talking about version resolution, yes, that's constraint solving on a language expressive enough to easily encode SAT |
| 2026-02-05 22:12:24 +0100 | <EvanR> | " |
| 2026-02-05 22:12:23 +0100 | <EvanR> | "The problem minimal version selection solves is NL-complete |
| 2026-02-05 22:11:59 +0100 | <EvanR> | though this random article about the theory seems interesting for its own sake https://research.swtch.com/vgo-mvs |
| 2026-02-05 22:10:34 +0100 | <EvanR> | \o/ |
| 2026-02-05 22:10:30 +0100 | <tomsmeding> | luckily I don't write go :) |
| 2026-02-05 22:10:24 +0100 | <tomsmeding> | ah |
| 2026-02-05 22:10:22 +0100 | <EvanR> | influencing the result |
| 2026-02-05 22:10:15 +0100 | <EvanR> | pkg-config giving different results for stuff not written in go |
| 2026-02-05 22:10:14 +0100 | <tomsmeding> | my use cases? |
| 2026-02-05 22:09:55 +0100 | <EvanR> | apparently go has a minimal version selection algorithm instead of a freeze file, and I'm not sure this is enough to deal with some of your use cases |
| 2026-02-05 22:06:16 +0100 | jmcantrell_ | jmcantrell |
| 2026-02-05 22:03:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-02-05 22:02:46 +0100 | <mauke> | (or a snapshot file in carton) |
| 2026-02-05 22:02:36 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-02-05 22:00:49 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 260 seconds) |
| 2026-02-05 22:00:00 +0100 | <tomsmeding> | (this idea of a "freeze file" is also called a "lock file" in different ecosystems; see also: package-lock.json, Cargo.lock, perhaps go.sum but I'm not sure I recall correctly there) |
| 2026-02-05 21:58:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-05 21:57:44 +0100 | wickedjargon | (~user@2605:8d80:5430:4910:f62b:7e78:f176:a13) wickedjargon |
| 2026-02-05 21:57:06 +0100 | <tomsmeding> | well this was your idea :p |
| 2026-02-05 21:56:57 +0100 | <EvanR> | you keep coming up with the best ideas! |
| 2026-02-05 21:56:39 +0100 | <EvanR> | yeah |
| 2026-02-05 21:56:34 +0100 | <tomsmeding> | and do that in Setup.hs, and change dependencies based on it? |
| 2026-02-05 21:56:11 +0100 | <EvanR> | get the phase of the moon as a bespoke sum type, or a float |
| 2026-02-05 21:55:21 +0100 | <EvanR> | wait that needs to be an acme package |
| 2026-02-05 21:55:19 +0100 | <tomsmeding> | or because system libraries changed and some pkg-config dependencies are now available or not available, different flags/packages are selected |
| 2026-02-05 21:54:55 +0100 | <tomsmeding> | :) |
| 2026-02-05 21:54:53 +0100 | <tomsmeding> | well, if one does `cabal update`, cabal may select newer versions |
| 2026-02-05 21:54:43 +0100 | <EvanR> | it checks the phase of the moon |
| 2026-02-05 21:54:26 +0100 | <EvanR> | I see, because without a freeze file cabal might come up with a different solution set in a different circumstances? |
| 2026-02-05 21:47:44 +0100 | yin | (~zero@user/zero) zero |
| 2026-02-05 21:46:56 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 240 seconds) |
| 2026-02-05 21:42:53 +0100 | <tomsmeding> | `cabal freeze` emits a "freeze file" with such constraints for everything (to make the build deterministic), and it emits any. constraints |
| 2026-02-05 21:42:29 +0100 | <tomsmeding> | writing `constraints: foo >= 2` constrains the main dependency tree only; writing `constraints: any.foo >= 2` also constrains build tool dependencies |
| 2026-02-05 21:42:19 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-02-05 21:42:06 +0100 | <tomsmeding> | it's part of the syntax of a `constraints:` block in a cabal.project file |
| 2026-02-05 21:41:54 +0100 | <tomsmeding> | (`cabal freeze`) |
| 2026-02-05 21:41:51 +0100 | <tomsmeding> | ah, then that was not a helpful reference |
| 2026-02-05 21:41:39 +0100 | <EvanR> | I'll have to read up on this freeze file you speak of |
| 2026-02-05 21:41:05 +0100 | <tomsmeding> | (I learned this the hard way) |
| 2026-02-05 21:40:55 +0100 | <tomsmeding> | this is relevant knowledge if you're trying to constrain the version of a dependency used to build a build tool; this is what the "any." in a cabal.project.freeze is for :p |
| 2026-02-05 21:40:52 +0100 | <EvanR> | that's convenient |
| 2026-02-05 21:40:16 +0100 | <tomsmeding> | EvanR: yes, but with caveats: in a single dependency tree, every package can indeed occur with only one version. However, cabal has the concept of a "build dependency", which is not linked in but used as an executable; typical examples are alex, happy, c2hs. Those have their _own_ dependency tree, and those trees can contain different versions |
| 2026-02-05 21:39:27 +0100 | Carlodiociottene | (~Carlodioc@host51.141-13-31.as49605.net) (Client Quit) |
| 2026-02-05 21:38:50 +0100 | Carlodiociottene | (~Carlodioc@host51.141-13-31.as49605.net) |
| 2026-02-05 21:36:10 +0100 | <EvanR> | that explains a lot xD |
| 2026-02-05 21:35:46 +0100 | <haskellbridge> | <Morj> Yes, there can only be one version of each package in the whole build tree |
| 2026-02-05 21:35:14 +0100 | <EvanR> | stupid question, when you are cabal building something, is there are most 1 version of each dependency "in use" for that build. And so if the same package comes up multiple ways, there needs to be an overlapping version bound |
| 2026-02-05 21:31:55 +0100 | <tomsmeding> | yes, `cabal build -j1` is a thing |