Logs: freenode/#haskell
| 2020-11-11 10:11:03 | <merijn> | Because now anything that functions can't be turned into is ruled out |
| 2020-11-11 10:11:25 | <merijn> | bqv: Category is in that sense more interesting |
| 2020-11-11 10:11:33 | <merijn> | :t (Control.Category..) |
| 2020-11-11 10:11:34 | <lambdabot> | forall k (cat :: k -> k -> *) (b :: k) (c :: k) (a :: k). Category cat => cat b c -> cat a b -> cat a c |
| 2020-11-11 10:11:38 | <merijn> | oof |
| 2020-11-11 10:11:46 | <merijn> | I forgot about the kind polymorphism |
| 2020-11-11 10:11:54 | <bqv> | Ha |
| 2020-11-11 10:11:58 | <merijn> | Pretend everything before the . is missing ;) |
| 2020-11-11 10:12:03 | <bqv> | Very generic |
| 2020-11-11 10:12:04 | <merijn> | :t Control.Category.id |
| 2020-11-11 10:12:05 | <lambdabot> | forall k (cat :: k -> k -> *) (a :: k). Category cat => cat a a |
| 2020-11-11 10:12:15 | <dminuoso> | asheshambasta: So ghc-pkg is the database for "available packages" |
| 2020-11-11 10:12:23 | <dminuoso> | you can register packages there, etc |
| 2020-11-11 10:12:37 | <dminuoso> | it's how manual ghc and cabal v1- worked |
| 2020-11-11 10:12:39 | × | alp quits (~alp@2a01:e0a:58b:4920:7dab:bd6a:30b1:7abd) (Ping timeout: 272 seconds) |
| 2020-11-11 10:12:45 | <merijn> | so you have (simplified): 'id :: Category cat => cat a a' and '(.) :: Category cat => cat b c -> cat a b -> cat a c' |
| 2020-11-11 10:13:10 | <dminuoso> | cabal v2- still uses this interface, but instead of maintaining this "global package database", cabal v2- generates a sort of transient package database based on its build plan, and tells ghc to use that instead. |
| 2020-11-11 10:13:10 | <merijn> | bqv: That's like half the composition stuff of Arrow, without needing to support functions |
| 2020-11-11 10:13:23 | <bqv> | Yeah, that makes sense |
| 2020-11-11 10:13:37 | <dminuoso> | asheshambasta: it seems as if the build planning consults ghc-pkg, which I think is strange because you're using new-style |
| 2020-11-11 10:13:40 | <merijn> | bqv: Do you know about contravariant functors? |
| 2020-11-11 10:13:52 | <bqv> | Yeah, via profunctors |
| 2020-11-11 10:14:26 | × | coot quits (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection) |
| 2020-11-11 10:14:31 | → | coco joins (~coco@212-51-146-87.fiber7.init7.net) |
| 2020-11-11 10:14:34 | <merijn> | bqv: Right, so profunctors are basically contravariant on one side and functors on the other side (which also mirrors a bunch of Arrow stuff, but again, without 'arr') |
| 2020-11-11 10:15:06 | <merijn> | bqv: So you can get most (all?) of the functionality of Arrow by mixing Category + Profunctor, but now you don't have to deal with that PITA 'arr' |
| 2020-11-11 10:15:14 | × | raichoo quits (~raichoo@213.240.178.58) (Quit: Lost terminal) |
| 2020-11-11 10:15:32 | <bqv> | Neat. So it's totally deprecated |
| 2020-11-11 10:15:37 | → | coot joins (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) |
| 2020-11-11 10:16:03 | <merijn> | Aside from some niche FRP libraries I don't think any modern/widely used library uses it |
| 2020-11-11 10:16:23 | <dminuoso> | asheshambasta: out of curiosity, if you use v2-repl instead of new-repl, does it still give the same errors? |
| 2020-11-11 10:16:47 | <bqv> | Heh |
| 2020-11-11 10:17:54 | <asheshambasta> | dminuoso: seems like it, yeah |
| 2020-11-11 10:18:30 | → | Aquazi joins (uid312403@gateway/web/irccloud.com/x-gthhcxtxtvdrftco) |
| 2020-11-11 10:19:03 | <dminuoso> | asheshambasta: Seems like that's the regular behavior then |
| 2020-11-11 10:19:09 | <dminuoso> | asheshambasta: do you use cabal v1- anywhere? |
| 2020-11-11 10:21:32 | <dminuoso> | asheshambasta: Anyhow. As an immediate hotfix, nuke/rename your ~/.ghc/{version}/environments/ |
| 2020-11-11 10:21:40 | <dminuoso> | And stop using cabal v1- I guess |
| 2020-11-11 10:21:58 | <dminuoso> | It's possible there is a more eloquent hotfix, possibly via cabal.project.local where you specify a custom package.db |
| 2020-11-11 10:23:01 | × | Sanchayan quits (~Sanchayan@122.181.216.76) (Quit: leaving) |
| 2020-11-11 10:23:22 | <dminuoso> | Im not actually sure what the right thing is, whether this is a bug, etc. At the very least I'd perhaps file an issue on cabal for documentation. |
| 2020-11-11 10:23:53 | <dminuoso> | (Naively it seems unreasonable for cabal v2-* to consider the ghc-pkg database for its build plan) |
| 2020-11-11 10:24:06 | <dminuoso> | It does so in 3.2.0.0 as well, I checked. |
| 2020-11-11 10:24:39 | <dminuoso> | Because by doing so, it's not really nix-style. cabal should *dictate* the package.db, not amend it. |
| 2020-11-11 10:25:08 | → | LKoen joins (~LKoen@77.174.9.109.rev.sfr.net) |
| 2020-11-11 10:25:27 | <merijn> | dminuoso: Actually, v2 *intentionally* disregards the package database |
| 2020-11-11 10:25:35 | <dminuoso> | merijn: evidently not? |
| 2020-11-11 10:25:39 | <merijn> | v1 used to consider it |
| 2020-11-11 10:26:02 | <dminuoso> | `cabal v2-build` specifically interrogates ghc-pkg before build planning |
| 2020-11-11 10:26:07 | <dminuoso> | Just run with -v3 in your projects and see |
| 2020-11-11 10:26:32 | <merijn> | The fact that it consults it doesn't mean it's used for buildplan resolution |
| 2020-11-11 10:27:32 | <asheshambasta> | dminuoso: should running `cabal v2-update` have an adverse effect on the system as a whole within `nix-shell`? |
| 2020-11-11 10:27:40 | <dminuoso> | asheshambasta: yeah |
| 2020-11-11 10:27:43 | <asheshambasta> | It seems like the packages that used to build earlier no longer build for me |
| 2020-11-11 10:27:47 | × | bitmagie quits (~Thunderbi@200116b8060ca30071501286c6dd94a1.dip.versatel-1u1.de) (Quit: bitmagie) |
| 2020-11-11 10:27:49 | × | mmohammadi9812 quits (~mmohammad@80.210.53.226) (Ping timeout: 264 seconds) |
| 2020-11-11 10:27:55 | <dminuoso> | asheshambasta: two things: |
| 2020-11-11 10:28:04 | <dminuoso> | a) that means you were lazy on your constraints |
| 2020-11-11 10:28:11 | <dminuoso> | b) cabal told you how to restore to the old index state |
| 2020-11-11 10:28:35 | <dminuoso> | (when you ran `cabal v2-update`) |
| 2020-11-11 10:28:44 | → | mmohammadi9812 joins (~mmohammad@5.117.38.198) |
| 2020-11-11 10:29:03 | <asheshambasta> | dminuoso: what can be done to fix it? |
| 2020-11-11 10:29:10 | <tomsmeding> | b) |
| 2020-11-11 10:30:05 | <dminuoso> | merijn: you're right though, Im making an educated guess that this is the cause |
| 2020-11-11 10:30:12 | <asheshambasta> | dminuoso: well, I ran `nix-shell --run 'cabal v2-update'` and then upon realising that this could cause issues, I killed it before it finished. It seems it had enough time to do some damage. |
| 2020-11-11 10:30:32 | <dminuoso> | merijn: but the fact that ghc-pkgs happens to list two entries for http-types, and the fact that the solver keeps talking about "installed-" packages.. |
| 2020-11-11 10:30:37 | <dminuoso> | It's an educated guess. |
| 2020-11-11 10:30:55 | <asheshambasta> | dminuoso, tomsmeding: for `b`, what can be done? Cabal doesnt' seem to be telling me how to restore the old state. |
| 2020-11-11 10:31:04 | <dminuoso> | asheshambasta: you should have let it run its course. |
| 2020-11-11 10:31:18 | <dminuoso> | asheshambasta: try running it again, and see if cabal state is healthy enough to report how to revert it |
| 2020-11-11 10:31:31 | <dminuoso> | if not, you have to bite the bullet and update your constraints |
| 2020-11-11 10:31:37 | <dminuoso> | but, you should be doing this anyway :) |
| 2020-11-11 10:31:49 | <asheshambasta> | or maybe this is unrelated though, I can run `nix-shell --run 'cabal new-repl' ` in other packages, just not in ~/.xmonad anymore (cannot find xmonad-contrib for some reason) |
| 2020-11-11 10:32:41 | <asheshambasta> | What does cabal v2-update do exactly? It seems to be calling hackage to update some index, but within a nix environment, do you want it to talk to hackage directly? |
| 2020-11-11 10:33:08 | <dminuoso> | asheshambasta: the nix-shell merely provides cabal-install the binary |
| 2020-11-11 10:33:13 | <dminuoso> | beyond that, there's nothing nixy about it |
| 2020-11-11 10:34:08 | <tomsmeding> | where does cabal even store the previous index states |
| 2020-11-11 10:34:30 | <merijn> | tomsmeding: It doesn't, the index is append only |
| 2020-11-11 10:34:37 | <merijn> | tomsmeding: So storing the previous index makes no sense |
| 2020-11-11 10:34:55 | <merijn> | tomsmeding: You can just "ignore the last part of the index" and achieve the same effect |
| 2020-11-11 10:35:03 | <tomsmeding> | makes sense |
| 2020-11-11 10:35:09 | <dminuoso> | asheshambasta: so there's two thoughts here: |
| 2020-11-11 10:35:21 | <merijn> | tomsmeding: In fact, that's literally what the index-state entry in cabal.project does :p |
| 2020-11-11 10:35:33 | <merijn> | It simply skips all entries after a certain timestamp |
| 2020-11-11 10:35:45 | <tomsmeding> | can't you then run the cabal update command with a random timestamp just before the concerned update command |
| 2020-11-11 10:35:54 | <dminuoso> | asheshambasta: either you want nix, but then you have to use `nix` instead of `cabal-install`. Then you could use callCabal2nix with shellFor (giving you interactive shells) |
| 2020-11-11 10:36:24 | <dminuoso> | asheshambasta: Or you want to do this with cabal. In order to get semi-deterministic builds, you have to either pin all versions - or if you're fine with automatic PVP conform updates, keep PVP conform package version constraints. |
| 2020-11-11 10:36:42 | <dminuoso> | If you maintain clean version constraints, `cabal v2-update` is fine |
| 2020-11-11 10:36:57 | <dminuoso> | (A good mind model could be to regularly run `cabal v2-update`, forcing yourself to adhere to proper constraints. |
| 2020-11-11 10:37:06 | <dminuoso> | And if your dependencies suck in that regard, dont use brittle dependencies. |
| 2020-11-11 10:37:52 | <bqv> | The nix shell might be a haskell shell, in which case all remote stores will be disabled in cabal |
| 2020-11-11 10:38:02 | <dminuoso> | bqv: no |
| 2020-11-11 10:38:14 | <dminuoso> | nix-shell merely sets up an environment with packages present. |
| 2020-11-11 10:38:39 | <bqv> | dminuoso: and environment variables |
| 2020-11-11 10:38:46 | <dminuoso> | Say `nix-shell -p ghc` ensures that you have a shell with a ghc in path. Roughly, nix-shell will synthesize a bin/ directory, containing symlinks to /nix/store |
| 2020-11-11 10:38:56 | <dminuoso> | And put that bin/ directory onto your PATH |
| 2020-11-11 10:39:05 | <dminuoso> | (There's a few more involved things, but roughly that's the extend of it) |
| 2020-11-11 10:39:18 | <bqv> | Don't forget the environment variables. Enter a ghc shell, it sets NIX_GHC etc. |
| 2020-11-11 10:39:28 | <dminuoso> | If you want *pinning*, you have to go the nix + callCabal2nix + shellFor route |
| 2020-11-11 10:39:40 | <bqv> | Thats what I meant |
All times are in UTC.