Newest at the top
| 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 |
| 2026-01-21 19:32:46 +0100 | <Milan_Vanca> | int-e: "ghc-pkg --user-package-db" should be able to pick libs installed with "cabal install --lib" ? |
| 2026-01-21 19:32:15 +0100 | <int-e> | Milan_Vanca: No, environment files are a third mechanic, separate from global and user package db |
| 2026-01-21 19:31:46 +0100 | danza | (~danza@user/danza) (Quit: got to go) |
| 2026-01-21 19:31:39 +0100 | <Milan_Vanca> | int-e: So cabal install --lib uses "local package db" and ghc-pkg is not aware of that right? |
| 2026-01-21 19:31:04 +0100 | <Milan_Vanca> | int-e: Exactly |
| 2026-01-21 19:30:54 +0100 | <Milan_Vanca> | gentauro: As I want to understand what is going on, which command does what. But as int-e pointed out the situation is more complicated |
| 2026-01-21 19:30:49 +0100 | <int-e> | gentauro: Because, I think, Milan_Vanca is just discovering how cabal[-install] works. |
| 2026-01-21 19:30:33 +0100 | <danza> | yeah int-e that's why recently i always use cabal from a dir with a .cabal file. Otherwise it gets confusing |
| 2026-01-21 19:29:44 +0100 | <gentauro> | Milan_Vanca: I'm understanding you want to list `binaries` installed by cabal right? Why not just `ls -lh ~/.cabal/bin`? |
| 2026-01-21 19:29:28 +0100 | <int-e> | Milan_Vanca: There's `cabal install --lib` but rather than adding to GHC's package database it creates an environment file. Which, annoyingly, is a feature that ghc-pkg isn't aware of. |
| 2026-01-21 19:28:37 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-01-21 19:28:22 +0100 | <danza> | you are speaking commands i rarely use, that's interesting |
| 2026-01-21 19:28:17 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-01-21 19:28:07 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 240 seconds) |
| 2026-01-21 19:28:03 +0100 | <int-e> | ...oh wow, v1-register is still around? |
| 2026-01-21 19:28:01 +0100 | <Milan_Vanca> | so "ghc-pkg list == cabal list --installed" to change this output one needs to "cabal register/unregister" instead of install |
| 2026-01-21 19:26:37 +0100 | <Milan_Vanca> | It looks like it shows same thing as "ghc-pkg list". Also there is "cabal register/unregister" and this goes to db in ghc-pkg? |
| 2026-01-21 19:25:02 +0100 | <int-e> | (I can see how this is confusing.) |
| 2026-01-21 19:24:49 +0100 | <Milan_Vanca> | gentauro: Yes that works :) I am just confused about "cabal install" and "cabal list --installed" not be connected? |
| 2026-01-21 19:24:00 +0100 | <Milan_Vanca> | danza: No that's not it :) I am in the same dir. |
| 2026-01-21 19:23:57 +0100 | <int-e> | yeah, it's not a "package" (not in the package database) |
| 2026-01-21 19:23:28 +0100 | <Milan_Vanca> | int-e: So the problem is it is executable and not lib? |
| 2026-01-21 19:22:57 +0100 | <gentauro> | Milan_Vanca: if `~/.cabal/bin` is in your PATH, then you should be able to exec and do `which alex` :) |