Newest at the top
| 2025-07-27 21:12:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-27 21:11:38 +0200 | sprotte24 | (~sprotte24@p200300d16f1c2800a4c46ead6c309f0b.dip0.t-ipconnect.de) |
| 2025-07-27 21:08:23 +0200 | LainIwakura50 | (~LainIwaku@user/LainIwakura) (Ping timeout: 272 seconds) |
| 2025-07-27 21:07:50 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 21:03:45 +0200 | hseg | (~gesh@46.120.20.122) (Ping timeout: 248 seconds) |
| 2025-07-27 21:00:44 +0200 | caconym74 | (~caconym@user/caconym) caconym |
| 2025-07-27 21:00:04 +0200 | jjanzen | (~user@user/jjanzen) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)) |
| 2025-07-27 21:00:03 +0200 | caconym74 | (~caconym@user/caconym) (Quit: bye) |
| 2025-07-27 20:56:58 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-07-27 20:56:51 +0200 | tromp | (~textual@2001:1c00:3487:1b00:dc37:ddbb:3dbd:472f) |
| 2025-07-27 20:54:13 +0200 | acidjnk | (~acidjnk@p200300d6e70b6692a4921e45644e17d7.dip0.t-ipconnect.de) acidjnk |
| 2025-07-27 20:52:25 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) Feuermagier |
| 2025-07-27 20:52:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 20:50:29 +0200 | Square2 | (~Square@user/square) (Ping timeout: 248 seconds) |
| 2025-07-27 20:50:28 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-07-27 20:47:28 +0200 | fp | (~Thunderbi@89-27-10-140.bb.dnainternet.fi) (Ping timeout: 240 seconds) |
| 2025-07-27 20:41:58 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds) |
| 2025-07-27 20:41:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-27 20:36:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-27 20:34:22 +0200 | <hseg> | [exa]: btw, I reported this as https://github.com/pypa/setuptools/issues/5054 |
| 2025-07-27 20:31:59 +0200 | <geekosaur> | neither have I, which is why I distrust "just use a sandbox" because you almost always in my experience end up changing versions of dependencies and then you're stuck |
| 2025-07-27 20:30:49 +0200 | turlando_ | (~turlando@user/turlando) (Ping timeout: 260 seconds) |
| 2025-07-27 20:30:40 +0200 | turlando | (~turlando@user/turlando) turlando |
| 2025-07-27 20:28:04 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
| 2025-07-27 20:27:30 +0200 | [exa] | yet has to see an experiment that went quick |
| 2025-07-27 20:25:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-27 20:25:21 +0200 | <EvanR> | "quickly write that script" not included, nor "save that script each time I reinstall my linux distro" |
| 2025-07-27 20:24:40 +0200 | <EvanR> | write the "quick experimentation" script which puts you in the holodeck program ready to do the experiment, then put that in your PATH |
| 2025-07-27 20:24:06 +0200 | <EvanR> | to make quick experimentation easy regardless of environment setup |
| 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) |