lix -

Age	Commit message (Collapse)	Author
2023-03-31	Ensure all headers have `#pragma once` and are in API docs	John Ericson
	`///@file` makes them show up in the internal API dos. A tiny few were missing `#pragma once`.
2023-01-30	Separate `path.hh` from `content-address.hh`	John Ericson
	It is good to separate concerns; `StorePath` (in general) has nothing to do with `ContentAddress` anyways. This reduces the diff from #3746.
2023-01-23	Better-scope `Store` forward declarations	John Ericson

2023-01-02	Fix why-depends for CA derivations (again)	Théophane Hufschmitt
	This has the same goal as b13fd4c58e81b2b2b0d72caa5ce80de861622610,but achieves it in a different way in order to not break `nix why-depends --derivation`.
2021-07-22	buildPaths(): Add an evalStore argument	Eelco Dolstra
	With this, we don't have to copy the entire .drv closure to the destination store ahead of time (or at all). Instead, buildPaths() reads .drv files from the eval store and copies inputSrcs to the destination store if it needs to build a derivation. Issue #5025.
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.