lix -

Age	Commit message (Collapse)	Author
2024-05-07	libutil: de-callback-ify computeClosure	eldritch horrors
	only two users of this function exist. only one used it in a way that even bears resemblance to asynchronicity, and even that one didn't do it right. fully async and parallel computation would have only worked if any getEdgesAsync never calls the continuation it receives itself, only from more derived callbacks running on other threads. calling it directly would cause the decoupling promise to be awaited immediately on the original thread, completely negating all nice async effects. Change-Id: I0aa640950cf327533a32dee410105efdabb448df
2023-05-08	libstore: also pass unwanted outputs to the post-build-hook	Yorick van Pelt

2022-01-19	Fix the build with nlohmann/json 3.10.4+	regnat

2021-07-16	Be more lenient when realisations have a conflicting dependency set	regnat
	- This can legitimately happen (for example because of a non-determinism causing a build-time dependency to be kept or not as a runtime reference) - Because of older Nix versions, it can happen that we encounter a realisation with an (erroneously) empty set of dependencies, in which case we don’t want to fail, but just warn the user and try to fix it.
2021-06-23	Assert that compatible realisations have the same dependencies	regnat
	Should always hold, but that’s not necessarily obvious, so better enforce it
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-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-04	Fix a whitespace issue	Théophane Hufschmitt
	Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
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.