| 9 Dec 2025 |
 Alex | In reply to @andromeda:tchncs.de
does anyone have a Nix flake that builds a package for Hackage without using Cabal? Like without having the 'redundancy' of a Nix build specification in the flake and a Cabal specification in the .cabal file?
builds a package for Hackage without using Cabal
AFAIK Hackage always requires a Cabal description by design. | 04:47:50 |
 andromeda | hmm I could use the metadata defined in the flake to create a .cabal at build time for reproducibility | 05:02:12 |
| andromeda | oder? | 05:02:28 |
| andromeda | 
Download 20251209_06h35m40s_grim.png | 05:35:58 |
| andromeda | goodness what is Cabal's problem /j | 05:36:10 |
|  terrorist :: Feline joined the room. | 06:47:19 |
 MangoIV | No and it’s both a bad idea and it’s misguided.
- nixpkgs haskell support (and Haskell.nix) uses cabal anyway so you don’t get around it
- nobody except nix users will be able to build your package
- nix flakes are even worse on that sense
- please don’t upload things to hackage that people cannot build for that reason.
My tip is to use cabal as the source of truth.
| 08:42:50 |
| andromeda | so I'm thinking that I a) use ghcWithPackages to get libraries through Nix b) use cabal-install nix package for building and c) make build scripts .sh files or something so someone without nix will have no trouble building it. Does that sound workable? | 08:58:10 |
 maralorn | @andromeda:tchncs.de I don't understand what you are trying to achieve. Writing a Haskell package builder for nix is a major undertaking why not use one of the existing ones? | 09:06:16 |
| maralorn | Ah, I was misunderstanding. | 09:07:31 |
| maralorn | But I am still unsure what you are trying to achieve. | 09:09:04 |
| andromeda | I want to be able to nix run .#debug to run my debug build, .#release for the release build, and .#docs to build Haddock into $out/docs. I currently have this implemented, but, as previously mentioned, people without Nix can't build it. By using Cabal as the actual build system and calling it from build scripts, I can use Nix as just a package manager which calls those same build scripts. Rather than using Nix as the package manager and build system like prior | 09:12:56 |
| andromeda | can I see an example of like a well-done flake for a haskell package? | 09:13:43 |
| andromeda | so like MangoIV said I would be using Cabal as the 'source of truth' and Nix just as a convenience dev environment for those who have it. | 09:16:05 |
| maralorn | Ah, I see | 09:16:24 |
| andromeda | Nix's flexibility is a blessing and a curse xD | 09:16:49 |
| maralorn | My best flake is probably this one others might have cleaner ones: https://github.com/maralorn/nix-output-monitor/blob/main/flake.nix | 09:19:33 |
| maralorn | But I am not saying that everything in there is recommended for every project | 09:20:20 |
| andromeda | yo you write nom!? Awesome! I use it every day | 09:20:38 |
| maralorn | Anyway the spirit of nixpkgs is generally to reuse language specific build instructions instead of dodging them. | 09:22:33 |
| maralorn | This is imo not a failure to separate concerns | 09:22:51 |
| maralorn | nix does not know anything about Haskell or cabal | 09:23:14 |
| maralorn | But nixpkgs is a suite of libraries to build projects from all kinds of ecosystems. Using such a library to build a Haskell package seems smart to me instead of redundant. | 09:24:32 |
| andromeda | I love that despite there being a 'right' way to do Nix, it's such a powerful and general tool that you can go literal years doing it the 'wrong' way without a hitch | 09:27:29 |
| maralorn | Also your approach seems slightly dishonest because when you use ghcWithPackages you still rely on tons of packages being built with our Cabal based builder and e.g. it uses bespoke code to put a DB in your environment which cabal-install understands. So you are not really getting rid of the layer mangling you are complaining about. | 09:28:11 |
| maralorn | That being said no one is stoping you from doing it your way. 😆 | 09:29:00 |
| maralorn | I personally think that the redundancy of the usual approach is not a problem. Because all the redundant information can be auto-generated on the nix side by cabal2nix. | 09:32:14 |
| andromeda | this is where I am now, I'll shift it to a Cabal-centered approach after school. Lmk if you have any other cool tips! | 09:35:32 |
|  Morj joined the room. | 10:44:13 |
| andromeda | I lied I'm going to mess around with FFI to see if I can get RGFW working instead of GLFW :) | 18:57:59 |
