lix -

Age	Commit message (Collapse)	Author
2021-06-23	Properly fail when trying to register an incoherent realisation	regnat

2021-06-23	Pass more values by reference	Théophane Hufschmitt
	Rather than copying them around everywhere Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
2021-05-26	Aso track the output path of the realisation dependencies	regnat

2021-05-26	Add a method to compute the closure of a realisation	regnat
	Only considers the closure in term of `Realisation`, ignores all the opaque inputs. Dunno whether that’s the nicest solution, need to think it through a bit
2021-05-26	Add a dependencies field to DrvOutputInfo	regnat
	Currently never used, nor set but will be useful shortly
2021-03-15	Add some logic for signing realisations	regnat
	Not exposed anywhere, but built realisations are now signed (and this should be forwarded when copy-ing them around)
2021-02-23	Make the build-hook work with ca derivations	regnat
	- Pass it the name of the outputs rather than their output paths (as these don't exist for ca derivations) - Get the built output paths from the remote builder - Register the new received realisations
2021-02-05	Remove the `visit` machinery in `RealisedPath`	regnat
	In addition to being some ugly template trickery, it was also totally useless as it was used in only one place where I could replace it by just a few extra characters
2021-02-05	Move the GENERATE_CMP macro to its own file	regnat
	Despite being an ugly hack, it can probably be useful in a couple extra places
2021-01-28	Add a new Cmd type working on RealisedPaths	regnat
	Where a `RealisedPath` is a store path with its history, meaning either an opaque path for stuff that has been directly added to the store, or a `Realisation` for stuff that has been built by a derivation This is a low-level refactoring that doesn't bring anything by itself (except a few dozen extra lines of code :/ ), but raising the abstraction level a bit is important on a number of levels: - Commands like `nix build` have to query for the realisations after the build is finished which is fragile (see 27905f12e4a7207450abe37c9ed78e31603b67e1 for example). Having them oprate directly at the realisation level would avoid that - Others like `nix copy` currently operate directly on (built) store paths, but need a bit more information as they will need to register the realisations on the remote side
2020-12-11	Use the hash modulo in the derivation outputs	regnat
	Rather than storing the derivation outputs as `drvPath!outputName` internally, store them as `drvHashModulo!outputName` (or `outputHash!outputName` for fixed-output derivations). This makes the storage slightly more opaque, but enables an earlier cutoff in cases where a fixed-output dependency changes (but keeps the same output hash) − same as what we already do for input-addressed derivations.
2020-12-11	Store the realisations as JSON in the binary cache	regnat
	Fix #4332
2020-12-11	Store metadata about drv outputs realisations	regnat
	For each known realisation, store: - its output - its output path This comes with a set of needed changes: - New `realisations` module declaring the types needed for describing these mappings - New `Store::registerDrvOutput` method registering all the needed informations about a derivation output (also replaces `LocalStore::linkDeriverToPath`) - new `Store::queryRealisation` method to retrieve the informations for a derivations This introcudes some redundancy on the remote-store side between `wopQueryDerivationOutputMap` and `wopQueryRealisation`. However we might need to keep both (regardless of backwards compat) because we sometimes need to get some infos for all the outputs of a derivation (where `wopQueryDerivationOutputMap` is handy), but all the stores can't implement it − because listing all the outputs of a derivation isn't really possible for binary caches where the server doesn't allow to list a directory.