Newest at the top
| 2025-07-27 20:18:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 20:10:20 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-07-27 20:09:36 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 265 seconds) |
| 2025-07-27 20:08:36 +0200 | <monochrom> | or s/CSE/flyweight/ if you don't know CSE but you know the flyweight design pattern. |
| 2025-07-27 20:07:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-07-27 20:06:39 +0200 | <monochrom> | IMO I don't describe cabal-v2 as full management, I describe it as sandbox with CSE. |
| 2025-07-27 20:04:40 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-07-27 20:03:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 19:56:45 +0200 | <hseg> | OK, will do |
| 2025-07-27 19:52:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-27 19:52:28 +0200 | <[exa]> | hseg: for pythons this might actually be a feature required by the ecosystem (eg for conda), so good luck there :) if you see any success please share |
| 2025-07-27 19:47:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 19:46:04 +0200 | alhazrod | (uid662262@user/alhazrod) alhazrod |
| 2025-07-27 19:44:43 +0200 | <geekosaur> | I had a discussion elsewhere with someone who insisted that we should switch to sandboxes because full package management makes quick experimentation difficult, but I don't think anyone has discovered something that both simplifies that and avoids the "must manage there being only a single version of a package visible" issue |
| 2025-07-27 19:43:30 +0200 | <geekosaur> | sometimes you still want something sandbox-ish. but sandboxes are just a localized version of "one version installed system-wide", so you still have the "one version installed" problem |
| 2025-07-27 19:39:39 +0200 | <hseg> | but otoh, once you have it, it obsoletes the need for sandboxes? |
| 2025-07-27 19:39:14 +0200 | <geekosaur> | it's the sandbox mechanic that imposes that requirement, multiple version management requires a more complex mechanic |
| 2025-07-27 19:38:44 +0200 | <geekosaur> | this is also why cabal sandboxes went away |
| 2025-07-27 19:38:35 +0200 | <geekosaur> | correct |
| 2025-07-27 19:37:26 +0200 | <hseg> | Right... which exposes the fact that since they don't really do multi-versioned installs, they expect an invariant of the form "if it installed, it's sane"? |
| 2025-07-27 19:36:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-27 19:33:50 +0200 | <geekosaur> | sandboxes really give you only one version of a package installed within it, cabal and stack can both handle multiple and expose the correct versions to the projects that need them |
| 2025-07-27 19:32:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 19:32:01 +0200 | <geekosaur> | note that a full implementation of this requires management of a package store like cabal and stack do, whereas python only has sandboxes |
| 2025-07-27 19:30:54 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-07-27 19:30:39 +0200 | <geekosaur> | right, they don't have a full constraint-solving installation plan generator |
| 2025-07-27 19:30:36 +0200 | <hseg> | (which given it's so popular, means that a certain packaging issue has gotten much less pressure than it should've) |
| 2025-07-27 19:30:09 +0200 | <hseg> | (just discovered python's setuptools doesn't do this, and in fact is entirely silent) |
| 2025-07-27 19:29:42 +0200 | <hseg> | excellent, thanks |
| 2025-07-27 19:28:49 +0200 | <geekosaur> | both will reject the installed versions while generating the build plan and build appropriate versions |
| 2025-07-27 19:28:13 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-07-27 19:27:47 +0200 | <hseg> | sanity-checking a feature request I'm making for another package manager -- given A depending on B>=b, B==b depending on C>=c, if you somehow accidentally manage to install B=b, C<c, will either cabal or stack notice that the transitive dependency is broken when generating their build plan? |
| 2025-07-27 19:25:49 +0200 | hseg | (~gesh@46.120.20.122) hseg |
| 2025-07-27 19:21:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-27 19:21:26 +0200 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-07-27 19:21:24 +0200 | visilii_ | (~visilii@213.24.126.48) (Ping timeout: 252 seconds) |
| 2025-07-27 19:20:57 +0200 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 252 seconds) |
| 2025-07-27 19:18:47 +0200 | visilii | (~visilii@213.24.127.253) |
| 2025-07-27 19:16:41 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-27 19:16:32 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 19:09:07 +0200 | acidjnk | (~acidjnk@p200300d6e70b6641f5079f6a9f0d0688.dip0.t-ipconnect.de) (Ping timeout: 276 seconds) |
| 2025-07-27 19:07:08 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: irc.renjuan.org (juan@acm.org)) |
| 2025-07-27 19:05:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-07-27 19:01:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 18:59:45 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-07-27 18:50:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-27 18:48:50 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-07-27 18:47:41 +0200 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-07-27 18:45:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 18:45:08 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |