<ptival[m]>
ah, well I guess that could work but it's a bit awkward to list your development tools in your project
<michaelpj1>
ptival: yeah, this is why I want https://github.com/haskell/cabal/issues/6952. For the time being we just build dev tools as additional `hackage-package`s on the side
<ptival[m]>
michaelpj: cool, good idea! what does it entail to build dev tools as additional `hackage-package`? I thought about putting something in `pkg-def-extras`, but I don't know how to obtain something of the expected "format" for packages not already on hackage... should I just look in the sources for how that `hackage` argument we receive is created?
<hexagoxel>
or is it too annoying to keep it up-to-date if you are not testing against 844?
<ptival[m]>
(OTOH, adding source-repository-package to cabal.project works great, thanks!)
<angerman>
hexagoxel: I think we took it out as it was putting too much strain on CI. I guess we could add them back and just not test them. Not sure what hamishmacks position on that is and how much work this will involve.
<hexagoxel>
Yeah I don't mind that it's not getting tested in your CI. But if it does not hurt to include the materialisations it would make setting up my CI slighly simpler. The only question is how bad the error message gets once the "non-maintained" materialisation gets out-of-date, which might be annoying for me and other users.
<michaelpj1>
then just pull out the exe and stuff it in your shell like any other executable tool
<michaelpj1>
hexagoxel: is there an issue about this? we can probably at least improve the error!
__monty__ has joined #haskell.nix
<hexagoxel>
oh, but the current error is not the problem. (it is not ideal either: it tells you "need materialisation for ghc844-foo, run this script" and when you run the script it tells you "hey, you are trying to modify nix store contents, aborting". But at least it is clear that ghc844 materialisations are missing.)
<hexagoxel>
I don't even know what the error is for out-of-date ghc844-foo materialisations
<michaelpj1>
I'm not sure what the right support policy is here, tbh. Leaving expressions in our repo that we don't test is always going to be a landmine, but removing them is probably even worse since then people can't even try and build it all themselves if they really want it
<michaelpj1>
and we already have 20-something GHCs in our test matrix, which doesn't make the CI machines very happy with us
<hexagoxel>
20? oh my
<hexagoxel>
yeah I understand the overhead for you. It's ok, I'll live with using a fork where I add a commit with materialisations.
<hexagoxel>
could put that into a "with-ghc-844-materialisations" branch that gets updated sporadically. But only if there are other parties interested.
<michaelpj1>
2 versions of nixpkgs x 4-5 versions of GHC x native/darwin/cross
<michaelpj1>
it's both horrifying and glorious (that it works!)
lemmih_ is now known as lemmih
fendor has joined #haskell.nix
<__monty__>
Re my question from yesterday about installing all the executables that come with a component. I'm currently using `buildEnv { paths = attrsets.attrvalues package.components.exes; }` (more or less). I take it there is no better way to go about this and I did in fact imagine the "components.<type>.all" attribute?
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 258 seconds]
hekkaidekapus} has joined #haskell.nix
hekkaidekapus{ has quit [Ping timeout: 240 seconds]
michaelpj1 has quit [Quit: killed]
domenkozar[m] has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
siraben has quit [Quit: killed]
jonge[m] has quit [Quit: killed]
ptival[m] has quit [Quit: killed]
jonge[m] has joined #haskell.nix
<__monty__>
Do these messages "trace: Using latest index state for arbtt!" mean I'm reevaluating my haskell.nix expressions every time? Is this because of IFD and would I use materialization to speed this up? (Just wondering whether I'm running a bunch of redundant stuff every time I rebuild my system.)
joshmeredith has quit [*.net *.split]
joshmeredith has joined #haskell.nix
michaelpj has joined #haskell.nix
<michaelpj>
__monty__: `collectComponents' "exes" pkgs` will get you all the executable components. That might well be what you want. The `all` component is gone (it was a hack that caused a lot of problems)
<michaelpj>
you will always re-evaluate your haskell.nix expressions: that's how Nix works. You evaluate the expression and that tells you what to build. If you've got IFD in there (which you will with haskell.nix unless you've materialized enough), then that will slow things down. I recommend materializing stuff!
Poscat[m] has joined #haskell.nix
domenkozar[m] has joined #haskell.nix
siraben has joined #haskell.nix
Ericson2314 has joined #haskell.nix
ptival[m] has joined #haskell.nix
<__monty__>
michaelpj: collectComponents (with a predicate for the package name I'm interested in) seems to be what I want but I have just one package as a result of a call to hackage-package and collectComponents expects a package set.
<__monty__>
I also came across haskell-nix.hackage is this a package set, it doesn't seem like it is?
<__monty__>
Ah, no, collectComponents doesn't give me what I want (I faked a package set by simply putting the hackage-package in an attrset).
<angerman>
__monty__: that hackage should be the set of all packages from hackage.
<angerman>
e.g. hackage, but readable by nix.
<__monty__>
It'd be useful if I wanted to get the exes from multiple packages. But for one package it's the same thing as package.components.exes.
<__monty__>
angerman: `haskell-nix.hackage.arbtt."0.10.2" = { revisions = [...]; sha256 = "..."; }` So it doesn't look like an ordinary package with components. More like metadata needed by hackage-package. Am I missing something?
<angerman>
__monty__: right, it's the input to the package construction.
<angerman>
__monty__: e.g. what `hackage-package` uses.
<angerman>
it's really just an implementaiton detail. Best to think of as "hackage database in nix".
<__monty__>
angerman: Ah ok, thanks. michaelpj: Thanks for the suggestions and explanation too : )
fendor has joined #haskell.nix
fendor__ has joined #haskell.nix
fendor_ has quit [Ping timeout: 272 seconds]
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 240 seconds]
fendor__ is now known as fendor
acarrico has joined #haskell.nix
fendor_ has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
fendor has quit [Remote host closed the connection]
Poscat[m] has left #haskell.nix ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
fendor has joined #haskell.nix
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 272 seconds]
fendor__ has joined #haskell.nix
fendor_ has quit [Ping timeout: 272 seconds]
o1lo01ol1o has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 265 seconds]
o1lo01ol1o has joined #haskell.nix
fendor__ has quit [Remote host closed the connection]
o1lo01ol_ has joined #haskell.nix
feepo has quit [Read error: Connection reset by peer]
feepo has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 240 seconds]
fendor has joined #haskell.nix
fendor has quit [Remote host closed the connection]