| 3 Nov 2024 |
 cdepillabout | In reply to @locallycompact-github:matrix.org
Is it possible to extend generic-builder and cabal2nix to deal with non-hackage cabal indices such as CHaP? So that it can understand cabal revisions on those package repositories in the same way as it does hackage. What's CHaP? | 09:02:11 |
 Daniel Firth | In reply to @maralorn:maralorn.de
I would kinda say yes, because the builder does not use indices at all. The builder does use hardcoded references to 'mirror://hackage/..." though. Whatever that is | 09:06:36 |
| Daniel Firth | In reply to @cdepillabout:matrix.org
What's CHaP? A cabal index for cardano packages. https://chap.intersectmbo.org/index.html | 09:07:10 |
| Daniel Firth | In reply to @locallycompact-github:matrix.org
A cabal index for cardano packages. https://chap.intersectmbo.org/index.html Build using https://github.com/input-output-hk/foliage | 09:07:26 |
|  @asymmetric:matrix.dapp.org.uk joined the room. | 10:48:44 |
| @asymmetric:matrix.dapp.org.uk | hi! i noticed that nix-tree is not at latest version in unstable, so i thought of updating it. but looking at the haskell section, it seems that hackage packages are updated en masse by subsystem maintainers through a specific process, rather than individually, and so that i shouldn't try to bump nix-tree myself. is that true? | 10:53:42 |
| @asymmetric:matrix.dapp.org.uk | * hi! i noticed that nix-tree is not at latest version in unstable, so i thought of updating it. but looking at the HACKING.md document, it seems that hackage packages are updated en masse by subsystem maintainers through a specific process, rather than individually, and so that i shouldn't try to bump nix-tree myself. is that true? | 10:56:22 |
| @asymmetric:matrix.dapp.org.uk | looking at this, it seems like hydra built the latest nix-tree successfully -- so IIUC this package lands in unstable as part of the haskell-updates PR, after all broken packges have been fixed/marked as such? | 10:59:30 |
 maralorn | In reply to @locallycompact-github:matrix.org
The builder does use hardcoded references to 'mirror://hackage/..." though. Whatever that is It can. But it can also just fetch tarballs, git repos, etc like every other builder in nixpkgs. | 11:00:10 |
 sterni (he/him) | you probably would need change cabal2nix and/or the generic builder, but it's not likely difficult | 11:12:29 |
| Daniel Firth | In reply to @maralorn:maralorn.de
It can. But it can also just fetch tarballs, git repos, etc like every other builder in nixpkgs. The problem with doing tarballs just via cabal2nix is that there's no tarball with the cabal revision in it. Maybe the simplest solution on my end is to override the source to include the revision file from the remote, but a proper solution with generic-builder and cabal2nix we could explore. I'm not sure how what's here could be parameterised to accomodate that though. | 11:29:12 |
| Daniel Firth | In reply to @sternenseemann:systemli.org
you probably would need change cabal2nix and/or the generic builder, but it's not likely difficult Right indeed. | 11:29:42 |
| sterni (he/him) | maralorn: hmm can we somehow filter out deprecated packages in the revdep calculation in the report š¤ | 11:31:52 |
| sterni (he/him) | Daniel Firth: how are repos defined in cabal-install? Ideally we just pass in the same kind of info and the builder can calculate the urls | 11:33:07 |
| sterni (he/him) | best case all stuff has to be the same and we can just pass a base url | 11:33:16 |
| Daniel Firth | In the cabal.project? | 11:33:47 |
| Daniel Firth | You just add this usually
repository cardano-haskell-packages
url: https://intersectmbo.github.io/cardano-haskell-packages
secure: True
root-keys:
3e0cce471cf09815f930210f7827266fd09045445d65923e6d0238a6cd15126f
...
| 11:34:38 |
| sterni (he/him) | okay then theoretically a repositoryUrl thing should be enough | 11:35:29 |
| sterni (he/him) | we just have to figure out how to best add support for that in cabal2nix then | 11:35:47 |
| sterni (he/him) | cabal.project was a mistakeā¦ https://github.com/pdobsan/oama/commit/7ba84ec43026b88ca0f372ae1828c472ae538795 | 11:35:52 |
| Daniel Firth | In reply to @sternenseemann:systemli.org
cabal.project was a mistakeā¦ https://github.com/pdobsan/oama/commit/7ba84ec43026b88ca0f372ae1828c472ae538795 I don't get it | 11:39:40 |
| Daniel Firth | In reply to @sternenseemann:systemli.org
okay then theoretically a repositoryUrl thing should be enough repositoryUrl as an argument to generic-builder? | 11:39:53 |
| sterni (he/him) | yes | 11:40:01 |
| sterni (he/him) | In reply to @locallycompact-github:matrix.org
I don't get it unrelated to what we were discussing | 11:40:12 |
| Daniel Firth | still curious | 11:40:30 |
| sterni (he/him) | I mean it's sort of fine still because we're not there yet compared to e.g. rust where you can have random git pins in your Cargo.lock | 11:42:03 |
| sterni (he/him) | but this sort of thing is a nightmare for packaging imo | 11:42:11 |
| maralorn | I don't get why need special support at all. Doesn't the alternative repo just expose a tarball for each package and we can create a derivation for that tarball? | 11:53:29 |
| Daniel Firth | The cabal revision files aren't ncluded | 11:54:15 |
| Daniel Firth | They are just stored on a url somewhere | 11:54:24 |
