| 1 Jun 2021 |
 sterni (he/him) | working on fixing tests.writers for darwin currently | 11:34:32 |
| sterni (he/him) | seems like there are some severe darwin regressions for GHC, it seems to be incapable of producing any binaries unless it is in an environment with stdenv | 11:35:02 |
| sterni (he/him) | so it works within a nix-shell and a build which is probably why no one noticed | 11:35:15 |
| sterni (he/him) | we really should separate the GHC wrapper script and the build itself | 11:41:53 |
| sterni (he/him) | changing a line in the script requires a full GHC build | 11:42:04 |
 Las | I am following https://haskell4nix.readthedocs.io/nixpkgs-users-guide.html#how-to-build-a-stand-alone-project, and doing nix-shell as described doesn't give me a cabal. Is the guide outdated? I've updated my nixpkgs recently. | 13:31:40 |
 maralorn | Las: That guide is written by someone who has cabal installed globally anyways. It doesn‘t claim, that it installs cabal-install, it just claims that calling cabal-install works. So if you don‘t want to install cabal globally you should add it to your shell.nix. And we should improve the documentation on that point. | 13:34:35 |
| Las | Well that means it should make cabal available | 13:34:56 |
| Las | It claims if I can do that then running it works | 13:35:02 |
| Las | Also, how would it work with --pure? | 13:35:48 |
| maralorn | It wouldn‘t. | 13:35:56 |
| maralorn | You are right. | 13:36:00 |
| maralorn | Anyways it has nothing to do with your nixpkgs being new. It’s just impure documentation. | 13:36:51 |
| maralorn | I think you should do something with shellFor and we should explain that in the docs. | 13:37:46 |
| Las | Does the infrastructure not internally use cabal to build packages? | 13:38:24 |
| Las | If it does use cabal, then IMO cabal should be included in the .env | 13:38:37 |
| maralorn | It uses Cabal the library, not cabal-install the binary. | 13:38:44 |
| Las | Ah | 13:38:55 |
| Las | So theoretically I could just run ghc from the env and also just use the library then | 13:39:12 |
| maralorn | Which is reasonable because that has less dependencies. | 13:39:13 |
| maralorn | Yes, you could. | 13:39:23 |
| maralorn | Allthough if your project has not Setup.hs you will need to make one yourself. | 13:39:49 |
| maralorn | * Although if your project has not Setup.hs you will need to make one yourself. | 13:40:02 |
| sterni (he/him) | generally we should advertise shellFor more, development environments and build environments are different things | 14:08:41 |
| maralorn | True | 14:09:18 |
 joe (he/him) | I really like developPackage | 14:10:08 |
| maralorn | I have no clue what the difference is … | 14:10:28 |
| maralorn | Why do we have both? | 14:10:35 |
| sterni (he/him) | developPackage does some callCabal2nix magic | 14:10:51 |
| sterni (he/him) | plus it can be both the derivation and the shell | 14:11:00 |
