Newest at the top
| 2026-01-21 20:56:18 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2026-01-21 20:51:58 +0100 | Brumaire | (~no@94.140.114.73) (Ping timeout: 244 seconds) |
| 2026-01-21 20:51:47 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-01-21 20:51:28 +0100 | Brumaire_ | (~no@2a01:e0a:576:3670:a4e5:6ca7:3f9a:ca2) Brumaire |
| 2026-01-21 20:49:47 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2026-01-21 20:40:38 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-01-21 20:40:35 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-01-21 20:40:05 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds) |
| 2026-01-21 20:37:03 +0100 | Googulator | (~Googulato@77-234-89-65.pool.digikabel.hu) |
| 2026-01-21 20:36:29 +0100 | Googulator | (~Googulato@77.234.89.65) (Quit: Client closed) |
| 2026-01-21 20:27:46 +0100 | jreicher | (~joelr@user/jreicher) (Quit: In transit) |
| 2026-01-21 20:27:37 +0100 | Zemy | (~Zemy@72.178.108.235) |
| 2026-01-21 20:25:04 +0100 | Zemy | (~Zemy@72.178.108.235) (Remote host closed the connection) |
| 2026-01-21 20:24:04 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 255 seconds) |
| 2026-01-21 20:19:33 +0100 | Enrico63 | (~Enrico63@host-79-42-228-73.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-01-21 20:19:30 +0100 | <Milan_Vanca> | Okey this makes sense.. :) Thank you |
| 2026-01-21 20:18:40 +0100 | <int-e> | Also, this mostly happened with older cabal-install (1.x) |
| 2026-01-21 20:18:07 +0100 | <int-e> | Milan_Vanca: The most common way a package breaks would be by upgrading a dependency, which replaces the dependency by a newer version (which is a different package). |
| 2026-01-21 20:17:42 +0100 | <Milan_Vanca> | Ah makes sense |
| 2026-01-21 20:17:01 +0100 | <int-e> | Milan_Vanca: I guess that's technically correct? ghc-pkg will only list broken packages that are installed though, so you end up with packages that have a missing or broken dependency. |
| 2026-01-21 20:16:08 +0100 | <Milan_Vanca> | And also "or the version number can be omitted in which case GHC will automatically expose the latest non-broken version from the installed versions of the package." So package can be installed and broken at the same time. |
| 2026-01-21 20:14:38 +0100 | <Milan_Vanca> | So "installed = in pkg db" "broken = not in pkg db".. I would say broken package is one in pkg db but somehow broken |
| 2026-01-21 20:14:00 +0100 | <Milan_Vanca> | Hmmm, how should I understand "broken" package? Is it "not installed"? From ghc docs 5.9.1 "GHC only knows about packages that are installed. Installed packages live in package databases." And "Additionally, some packages may be broken: that is, they are missing from the package database, or one of their dependencies are broken" |
| 2026-01-21 20:03:53 +0100 | spew_ | (~spew@user/spew) (Ping timeout: 260 seconds) |
| 2026-01-21 20:02:29 +0100 | spew__ | spew |
| 2026-01-21 20:02:27 +0100 | spew | (~spew@user/spew) (Killed (NickServ (GHOST command used by spew__))) |
| 2026-01-21 20:02:02 +0100 | spew__ | (~spew@user/spew) spew |
| 2026-01-21 19:59:10 +0100 | spew_ | (~spew@user/spew) spew |
| 2026-01-21 19:54:44 +0100 | Tuplanolla | (~Tuplanoll@85-156-32-207.elisa-laajakaista.fi) Tuplanolla |
| 2026-01-21 19:48:01 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-01-21 19:47:03 +0100 | <int-e> | leave the messy bits of informing ghci about the packages to cabal |
| 2026-01-21 19:46:08 +0100 | <int-e> | yeah that's the idea |
| 2026-01-21 19:45:54 +0100 | redshuffle | (~quassel@45.43.70.75) |
| 2026-01-21 19:45:29 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-01-21 19:45:10 +0100 | <Milan_Vanca> | I am not sure I uderstand.. so when project has dependencies that are not glboaly installed, then its better to "cabal repl" instead of ghci right? |
| 2026-01-21 19:45:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-01-21 19:44:37 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-01-21 19:39:31 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-01-21 19:39:04 +0100 | <int-e> | *standalone |
| 2026-01-21 19:38:57 +0100 | <int-e> | And then do what danza said: Don't work with standalong ghc(i) at all if there are any non-standard dependencies. |
| 2026-01-21 19:38:21 +0100 | <int-e> | Personally I use GHC_ENVIRONMENT=- which disables them (and then occasionally unset that variable) |
| 2026-01-21 19:38:03 +0100 | <Milan_Vanca> | thanks |
| 2026-01-21 19:37:44 +0100 | <int-e> | Milan_Vanca: for details on environments (including where GHC looks for them), see https://downloads.haskell.org/ghc/latest/docs/users_guide/packages.html#package-environments |
| 2026-01-21 19:35:21 +0100 | <Milan_Vanca> | BRB.. and thank you for answers :) |
| 2026-01-21 19:35:07 +0100 | <Milan_Vanca> | Ookey I should just read whole doc and then ask questions :D |
| 2026-01-21 19:34:22 +0100 | <int-e> | It's all rather messy, for historical reasons and possibly having too many cooks. |
| 2026-01-21 19:34:20 +0100 | <Milan_Vanca> | Ok so there is global package db, user package db, and project env. |
| 2026-01-21 19:33:44 +0100 | <int-e> | Milan_Vanca: ghc-pkg will take the user package db into account by default |
| 2026-01-21 19:33:30 +0100 | <int-e> | Their purpose is to be context dependent (you can have an environment in a project directory, and ghc will pick it up unless instructed not to) |
| 2026-01-21 19:33:00 +0100 | <Milan_Vanca> | int-e: Aaah :D |