Newest at the top
| 2025-01-20 19:50:57 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-20 19:50:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-20 19:47:20 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-01-20 19:46:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-20 19:45:43 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-20 19:43:07 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2025-01-20 19:42:47 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-20 19:42:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-20 19:41:38 +0100 | <haskellbridge> | <alexfmpe> git remote add originOrSo /my/local/path |
| 2025-01-20 19:41:16 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-20 19:41:14 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-01-20 19:40:18 +0100 | <haskellbridge> | <alexfmpe> Yeah can be local, I've done it often |
| 2025-01-20 19:39:44 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 265 seconds) |
| 2025-01-20 19:39:33 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-20 19:38:51 +0100 | acidjnk | (~acidjnk@p200300d6e7283f8095cc0997f421f19c.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-20 19:37:02 +0100 | <tomsmeding> | note, a git repo need not be remote, it can also be a directory on the local system iirc |
| 2025-01-20 19:36:21 +0100 | mengu1 | (~mengu1@88.253.125.86) |
| 2025-01-20 19:35:41 +0100 | <tomsmeding> | right -- "inplace", not "in-place" |
| 2025-01-20 19:35:20 +0100 | <tomsmeding> | oh isn't the in-place thing for components of the current package? |
| 2025-01-20 19:35:12 +0100 | <hellwolf> | I see. I will experiment that strategy too |
| 2025-01-20 19:34:44 +0100 | <tomsmeding> | I just checked with a project where I have a 'source-repository-package' stanza in cabal.project that points to a git repo; that thing gets a proper package ID |
| 2025-01-20 19:33:40 +0100 | <tomsmeding> | oh are they not put in the store? |
| 2025-01-20 19:33:25 +0100 | <hellwolf> | not usable for packge-id |
| 2025-01-20 19:33:20 +0100 | <hellwolf> | the problem with dist-newstyle/cache/plan.json is that for locally build project, they are decorated with "xxx-in-place" |
| 2025-01-20 19:30:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-20 19:29:50 +0100 | <tomsmeding> | (this is what the playground's mkbuildscript.sh is essentially doing) |
| 2025-01-20 19:29:30 +0100 | <tomsmeding> | and roll with that |
| 2025-01-20 19:29:26 +0100 | <tomsmeding> | pick the package ID from dist-newstyle/cache/plan.json |
| 2025-01-20 19:29:16 +0100 | <tomsmeding> | now it's in the store |
| 2025-01-20 19:29:12 +0100 | <tomsmeding> | make a cabal project, use the thing you want in the store in that project, build the project with that store path |
| 2025-01-20 19:28:52 +0100 | <tomsmeding> | then don't destroy it, but instead just install the new thing you need in it :p |
| 2025-01-20 19:28:36 +0100 | <hellwolf> | tomsmeding: it's a good idea; it is just that it takes 20 minutes to build the db from scratch :p |
| 2025-01-20 19:28:12 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-20 19:27:57 +0100 | <tomsmeding> | ensure you don't need to care about what else is roaming around in that store |
| 2025-01-20 19:27:48 +0100 | <tomsmeding> | e.g. don't try to find out "the latest from the store", just install what you need in the store and get the package ID from that installation procedure somehow |
| 2025-01-20 19:27:18 +0100 | <tomsmeding> | but it's better for your sanity if you don't, I think |
| 2025-01-20 19:27:11 +0100 | <tomsmeding> | perhaps you can |
| 2025-01-20 19:26:58 +0100 | <tomsmeding> | hellwolf: I now read the backlog more properly. I recommend treating the cabal store as a disposable thing: create it programmatically, and if you need a different one, destroy it and create a new one. Don't try to play surgeon on what's in there |
| 2025-01-20 19:26:53 +0100 | <hellwolf> | yea, I just wanted to keep a unique latest instance, for now. |
| 2025-01-20 19:24:41 +0100 | <tomsmeding> | (if you don't want to just nuke the entire store) |
| 2025-01-20 19:24:25 +0100 | <tomsmeding> | actually freeing up disk space is harder and requires something like https://github.com/treblacy/cabalgc |
| 2025-01-20 19:24:20 +0100 | <hellwolf> | I am using --store-db, fwiw. You know the playground project. |
| 2025-01-20 19:24:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-20 19:24:03 +0100 | <tomsmeding> | again, leaving the build products still in ~/.cabal/ |
| 2025-01-20 19:24:03 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-01-20 19:23:58 +0100 | <tomsmeding> | if you did `cabal install` on an executable, then just removing the symlink in ~/.cabal/bin/ will "uninstall" it |
| 2025-01-20 19:23:43 +0100 | <hellwolf> | I also discovered ghc-pkg recache command |
| 2025-01-20 19:23:37 +0100 | <tomsmeding> | the build products still still be there in ~/.cabal/, but they won't be used, so they're just costing you disk space |
| 2025-01-20 19:23:18 +0100 | <tomsmeding> | you can just remove the file in there and it's gone |
| 2025-01-20 19:23:10 +0100 | <tomsmeding> | hellwolf: if you did `cabal install --lib`, it's now in .ghc/<platform>/environments/ |