| Age | Commit message (Collapse) | Author |
|---|
|
Proposal: Use C++20
|
|
Ca/fix nix log
|
|
|
|
Fix #6209
When trying to run `nix log <installable>`, try first to resolve the derivation pointed to
by `<installable>` as it is the resolved one that holds the build log.
This has a couple of shortcomings:
1. It’s expensive as it requires re-reading the derivation
2. It’s brittle because if the derivation doesn’t exist anymore or can’t
be resolved (which is the case if any one of its build inputs is missing),
then we can’t access the log anymore
However, I don’t think we can do better (at least not right now).
The alternatives I see are:
1. Copy the build log for the un-resolved derivation. But that means a
lot of duplication
2. Store the results of the resolving in the db. Which might be the best
long-term solution, but leads to a whole new class of potential
issues.
|
|
|
|
|
|
|
|
|
|
Also use std::string_view in a few more places.
|
|
|
|
|
|
|
|
|
|
These were needed back in the pre-C++11 era because we didn't have
move semantics. But now we do.
|
|
async realisation substitution
|
|
Allow references in addPath
|
|
Co-Authored-By: Eelco Dolstra <edolstra@gmail.com>
|
|
Since 4806f2f6b0fd2cae401b89fe19d8c528ffd88b5f, we can't have paths with
references passed to builtins.{path,filterSource}. This prevents many cases
of those functions called on IFD outputs from working. Resolve this by
passing the references found in the original path to the added path.
|
|
That way we can fetch several realisations from the same cache in
parallel
|
|
Doesn’t change much so far because everything is still using it
synchronously, but should allow the binary cache to fetch stuff in
parallel
|
|
Allow to pass a set of references to be added as info to the added paths.
|
|
This fixes a bug in the garbage collector where if a path
/nix/store/abcd-foo is valid, but we do a
isValidPath("/nix/store/abcd-foo.lock") first, then a negative entry
for /nix/store/abcd is added to pathInfoCache, so /nix/store/abcd-foo
is subsequently considered invalid and deleted.
|
|
Based off on @dtzWill's #2276
|
|
|
|
Signed-off-by: Pamplemousse <xav.maso@gmail.com>
|
|
I never remember the exact syntax of the `switch` statement
|
|
Similar to the nar-info disk cache (and using the same db).
This makes rebuilds muuch faster.
- This works regardless of the ca-derivations experimental feature.
I could modify the logic to not touch the db if the flag isn’t there,
but given that this is a trash-able local cache, it doesn’t seem to be
really worth it.
- We could unify the `NARs` and `Realisation` tables to only have one
generic kv table. This is left as an exercise to the reader.
- I didn’t update the cache db version number as the new schema just
adds a new table to the previous one, so the db will be transparently
migrated and is backwards-compatible.
Fix #4746
|
|
|
|
Was crashing because coercing a json document into a string is only
valid if the json is a string, otherwise we need to call `.dump()`
|
|
Because of a too eager refactoring, `addTextToStore` used to throw an
error because the input wasn't a valid nar.
Partially revert that refactoring to wrap the text into a proper nar
(using `dumpString`) to make this method work again
|
|
Fix #4332
|
|
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.
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
|
|
We don't need it yet, but we could/should in the future, and it's a
cost-free change since we already have the reference. I like it.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
This gets rid of the inclusion of <future> in util.hh, cutting
compilation time by ~20s (CPU time).
Issue #4045.
|
|
Rework the `Store` hierarchy so that there's now one hierarchy for the
store configs and one for the implementations (where each implementation
extends the corresponding config). So a class hierarchy like
```
StoreConfig-------->Store
| |
v v
SubStoreConfig----->SubStore
| |
v v
SubSubStoreConfig-->SubSubStore
```
(with virtual inheritance to prevent DDD).
The advantage of this architecture is that we can now introspect the configuration of a store without having to instantiate the store itself
|
|
Make narHash in ValidPathInfo not optional
|
|
|
|
These are not supposed to include the 'name' part of the store
path. This was broken by 759947bf72.
|
|
|
|
Since the hash is not optional anymore
|
|
|
|
The file sink is also flushed in its destructor, but we ignore any
exceptions in the destructor.
Issue #3886.
|
|
Fixes #3891.
|
