<angerman>
elvishjerricco: with the component builder
<gchristensen>
hrm :/ I thought nix 2.1.1 had the fixes for copying big files to the nix store?
<clever>
this build initially fired up 60 derivations in parallel, and nearly crippled my machine
<clever>
and `nix build` doesnt understand -j
<angerman>
clever: you clearly need more cores! :p
<elvishjerricco>
angerman: Yea I commented in the PR an example how to use it
<angerman>
elvishjerricco: ahh sorry, didn't see it yet.
<elvishjerricco>
clever: --max-jobs?
<clever>
elvishjerricco: heh, it wont stop when i ctrl+c!
<elvishjerricco>
Lol
<angerman>
has anyone successfully used cachix with travis+nix+osx?
<angerman>
elvishjerricco: that build is pretty cool. you could have just used hackage.nix and stackage.nix repos though instead of generating them yourself :D
<elvishjerricco>
angerman: Not quite. Wanted to do it differently for revisions.
<elvishjerricco>
Which are pretty critical to Stack age
<elvishjerricco>
Also flags
<angerman>
elvishjerricco: flags sure; that's something I wanted to fix. but why are revisions so critical?
<elvishjerricco>
IIRC I couldn't even build cabal-install with the latest revisions of versions in the Stackage snapshot I was testing. It's pretty important to be using the Cabal files that Stackage expects since it's so common for revisions to break a snapshot
<elvishjerricco>
angerman: ^
<angerman>
elvishjerricco: due to version bounds?
<elvishjerricco>
Yep.
<angerman>
elvishjerricco: I've started to completely ignore them when using snapshots
<elvishjerricco>
That's fair
<angerman>
essentially sidestepping any of cabals solving mechanism.
<elvishjerricco>
Still. I really wanted proper revision support :P
<angerman>
it's a curated (pre-solved) set anyway, ./Setup build should just build the stuff and not try to solve it.
<angerman>
fair enough :-)
<angerman>
elvishjerricco: I'm not against using hackagedb to generate the hackage.nix set instead of the all-cabal-... stuff
<elvishjerricco>
angerman: Yea. all-cabal-hashes seems like a totally unnecessary indirection to me
<elvishjerricco>
Like, why write data when you could write code? :P
<angerman>
homoiconoicity
<elvishjerricco>
That was a new word for me :P
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
mic921 has quit [Ping timeout: 250 seconds]
timokau[m] has quit [Ping timeout: 250 seconds]
yegortimoshenko has quit [Ping timeout: 276 seconds]
roberth has quit [Ping timeout: 250 seconds]
bgamari has quit [Ping timeout: 260 seconds]
yegortimoshenko has joined #nixos-dev
roberth has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 246 seconds]
lassulus_ is now known as lassulus
florianjacob has quit [Ping timeout: 252 seconds]
pie__ has joined #nixos-dev
florianjacob has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 252 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis has quit [Ping timeout: 260 seconds]
pie__ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
goibhniu has quit [Ping timeout: 244 seconds]
sir_guy_carleton has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
mic921 has joined #nixos-dev
<sphalerite>
gchristensen: andi-: ♥
<sphalerite>
LnL: sigh, the perils of using an alias in some places and a real name in others
<LnL>
heh :)
<LnL>
it's also possible I actually knew at some point and forgot
goibhniu has joined #nixos-dev
<Taneb>
sphalerite: your IRC name tends to remind me of Dwarf Fortress
<globin>
samueldr, gchristensen: wrt azure maybe fadenb can help
<sphalerite>
Taneb: well it's a real-life rock :p
<srhb>
I get the same. Also conflation with the fictional "saphirite" from a factorio mod...
<srhb>
Oops, thought this was -chat
<fadenb>
globin: at the moment I am no longer using Azure
pie__ has joined #nixos-dev
thefloweringash has quit [Ping timeout: 276 seconds]
thefloweringash has joined #nixos-dev
phreedom_ is now known as phreedom
Jackneill has quit [Read error: Connection reset by peer]
<{^_^}>
#45890 (by lopsided98, 5 weeks ago, open): buildbot: Python 3 support and other improvements
<lopsided98>
The PR was reviewed when I submitted it, but it has been ignored since then
drakonis_ has joined #nixos-dev
<infinisil>
lopsided98: Left some feedback, am willing to merge once that's addressed (and the bot can run the tests successfully) :)
<lopsided98>
infinisil: Thanks, I'm looking at it now
drakonis_ has quit [Quit: Leaving]
drakonis_ has joined #nixos-dev
<clever>
Ericson2314: ive been working on a patch to generic-builder.nix, which will run haskell tests in a seperate derivation
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
<elvishjerricco>
clever: That sounds quite nice
<clever>
elvishjerricco: my current method of attack, is to add another output, testdata, and then the checkPhase simply doesnt run the tests, and the installPhase copies all test binaries to $testdata/bin/
<clever>
elvishjerricco: then using passthru i add a .testrun attribute to every package, which will re-run the unpackPhase, and then run the test binaries
<clever>
and finally, a allTestsInClosure attr, that will walk the haskell deps (via getBuildInputs.haskellBuildInputs) and refer to every .testrun
<elvishjerricco>
clever: In my ideal world, building `haskellPackages.foo` will build both the lib and the tests (and building the tests will require building the tests of all dependencies), but the lib derivation only depends on other lib derivations
drakonis has quit [Ping timeout: 250 seconds]
<clever>
thats basically what i have
<clever>
but you can run the tests for any given package, without running the tests of its deps
<elvishjerricco>
clever: Hah. Well wait if your idea is to build the tests and just copy them to $out, then it'll still increase the build times by actually building the tests. That's unfortunate.
<clever>
elvishjerricco: yeah, splitting it up by component is better, but i wasnt sure how to do that just yet
<clever>
and it needs more metadata at the nix level, which angerman's stuff gives you easy access to
<elvishjerricco>
clever: If you're willing to require 8.2, you could just install the library to $out, then in the test derivation you could iterate over all the tests and reconfigure to build just that test and do them one at a time.
<clever>
in my case, just running the test can sometimes take an hour
<elvishjerricco>
clever: since the Cabal in 8.2 allows you to configure just one component at a time.
<clever>
so the cost of compiling the test is cheap
<elvishjerricco>
Still, seems unfortunate to put irrelevant test binaries in the output
<clever>
they are in a seperate output, so you can GC them if they are of no use
<clever>
outputs = [ "out" "testdata" ];
<elvishjerricco>
clever: Is 8.2 too strong a restriction? If not, I can help you with building the tests in the test derivation
<clever>
i'm already using 8.2.2
<clever>
its more that i need to read the cabal file and get a list of things, when generic-builder.nix is called, and that involves IFD
<clever>
but when using angerman's tools, your already reading the cabal files and pre-generating nix files, so its simpler
<elvishjerricco>
clever: Is there not a way to iterate over the names of the test components just with Setup.hs? No need for IFD
<clever>
i checked, and there isnt, i'm currently using some haskell that links against Cabal and reads the files configure generates
<clever>
but you could make it more coarse, if `isExecutable` is true, then build all executables as a single derivation
<clever>
if `isLibrary`, build the lib as a single derivation
<clever>
if both, then the executables depend on the library
<clever>
and if `doCheck`, repeat the same logic as executables
<clever>
but things get messy when you start to depend on things
<clever>
when you depend on a haskell package, did you want the library? the executables? both?
<elvishjerricco>
clever: That's tricky
<elvishjerricco>
If it's a build-tool dependency, then you want the exes. If it's a build-depends dependency, then you want the lib
<clever>
and i think cabal2nix will encode that as libraryHaskellDepends+executableHaskellDepends vs libraryToolDepends+executableToolDepends+testToolDepends
<elvishjerricco>
Oh really? That's neat
drakonis1 has joined #nixos-dev
<clever>
this also allows generic-builder.nix to exclude all the executable deps, if you set isExecutable = false;
<clever>
and some of our depdency cycles are broken, by `doCheck = false` also excluding the testToolDepends and testHaskellDepends
<clever>
i have re-discovered those, when i used an overlay to globally doCheck = true;
<elvishjerricco>
Man, I really want to go deeper on my per-component builder. generic-builder has a accumulated a lot of cruft over the ages.