docs(tvix): remove differences-drv-paths.md
This was true while we didn't do string contexts, but drvPath should not differ anymore. Change-Id: I58e6ed439519bd4d68259d1577946f3c65110dc4 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11074 Tested-by: BuildkiteCI Reviewed-by: edef <edef@edef.eu> Autosubmit: flokli <flokli@flokli.de>
This commit is contained in:
parent
c9514b7c0c
commit
b0e5a932ec
2 changed files with 0 additions and 36 deletions
|
@ -2,7 +2,6 @@
|
||||||
|
|
||||||
# Tvix
|
# Tvix
|
||||||
- [Architecture & data flow](./architecture.md)
|
- [Architecture & data flow](./architecture.md)
|
||||||
- [.drvPath inconsistencies](./differences-drv-paths.md)
|
|
||||||
|
|
||||||
# Nix
|
# Nix
|
||||||
- [Specification of the Nix Language](./language-spec.md)
|
- [Specification of the Nix Language](./language-spec.md)
|
||||||
|
|
|
@ -1,35 +0,0 @@
|
||||||
# .drvPath inconsistencies / Why .drvPath differs between Nix and Tvix
|
|
||||||
|
|
||||||
Nix and Tvix currently use a different approach when it comes to tracking input
|
|
||||||
references, in order to build the right dependencies in advance.
|
|
||||||
Nix is using string contexts, whereas Tvix is doing reference scanning [^inbox-drvpath].
|
|
||||||
|
|
||||||
There are some real-life cases, for example during nixpkgs bootstrapping, where
|
|
||||||
multiple different fixed-output derivations are written to produce the same
|
|
||||||
hash.
|
|
||||||
|
|
||||||
For example, bootstrap sources that are downloaded early are fetched using
|
|
||||||
a special "builder hack", in which the `builder` field of the derivation is
|
|
||||||
populated with the magic string `builtin:fetchurl` and the builder itself will
|
|
||||||
perform a fetch, with everything looking like a normal derivation to the user.
|
|
||||||
|
|
||||||
These bootstrap sources are later on defined *again*, once `curl`is available,
|
|
||||||
to be downloaded using the standard pkgs.fetchtarball mechanism, but yielding
|
|
||||||
the *same* outputs (as the same files are being fetched).
|
|
||||||
|
|
||||||
In our reference scanning implementation, this output scanning of FOD will
|
|
||||||
cause the path of the *first* derivation producing the given fixed output to be
|
|
||||||
stored in the `inputDrvs` field of the derivation, while Nix will point to the
|
|
||||||
derivation that was actually used.
|
|
||||||
|
|
||||||
This doesn't cause any differences in the calculated *output paths*, as paths to
|
|
||||||
fixed-output derivations are replaced with a special
|
|
||||||
`fixed:out:${algo}:${digest}:${fodPath}` string that doesn't contain the "path
|
|
||||||
to the wrong derivation" anymore.
|
|
||||||
|
|
||||||
As we haven't fully determined if our reference scanning approach is gonna work,
|
|
||||||
and comparing output paths is sufficient to determine equality of the build
|
|
||||||
instructions, this is left as a future work item.
|
|
||||||
|
|
||||||
|
|
||||||
[^inbox-drvpath]: https://inbox.tvl.su/depot/20230316120039.j4fkp3puzrtbjcpi@tp/T/#t
|
|
Loading…
Reference in a new issue