<sphalerite>
or rather: why did you ping me? Pretty sure you had a reason :p but I can't really do anything to advance it, either niksnut merges it as is or netboot has to improve first. I do want to improve netboot at some point, but that point is still in the future :)
<mic921>
fair enough
genesis has quit [Remote host closed the connection]
sir_guy_carleton has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.0]
genesis has joined #nixos-dev
<Synthetica>
sphalerite: mic921: Does either of you have admin access on hydra.nixos.org? (I'm just gonna keep bugging everyone here until someone has it :P)
jtojnar has quit [Ping timeout: 244 seconds]
<gchristensen>
Synthetica: my only hesitation is we need to be careful about build jobsets on non-nixos repos. if some people vouch for you, I can do it.
<gchristensen>
on a quickscan, it looks pretty good
sir_guy_carleton has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
sir_guy_carleton has quit [Quit: WeeChat 2.2]
drakonis1 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 272 seconds]
bgamari_ has joined #nixos-dev
catern has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
<catern>
dear #nixos-dev, here's an idea for you: what if nix-instantiate operated on an in-memory store during instantiation, so that it didn't have to call out to the real store for each and every derivation instantiation? then at the end, nix-instantiate could just copy from the in-memory store to the real store - which would be much cheaper because it would only have to copy derivations that weren't already in the real store, instead of
<catern>
recursing over the entire tree!
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined #nixos-dev
<niksnut>
catern: yes, I would like to get rid of .drv files entirely
<niksnut>
i.e. the evaluator just builds an in-memory representation of the build graph and then builds the missing paths
<clever>
it can already do that, when operating in read-only mode, but i would like to keep the .drv files, both for debug (nix show-derivation) and to allow rebuilding and manual remote builds, and nix-diff
<catern>
niksnut: I see, so instead of buildPaths taking a list of paths of .drv files, it would take a list of in-memory equivalents?
<catern>
that does seem nicer
<niksnut>
yes, there already is buildDerivation() that takes an in-memory representation of a derivation
<catern>
clever: I think you could still have an on-disk representation of .drv files, they just wouldn't need to be in the store
<catern>
(then you could still do all those things you mentioned)
<clever>
catern: and currently, nix-diff only accepts files in the store, i had trouble when the drv files where in a gist
<catern>
clever: you say that the Nix evaluator already knows how to be only in-memory, when operating in read-only mode? can you actually use the resulting in-memory derivations though?
<clever>
hmmm, never tried, but it can emit paths to .drv files, that dont actually get made
<niksnut>
currently, in read-only mode the derivation info is discarded, so you can't use it to build yet