mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(tvix): remove differences-drv-paths.md

Browse source 
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:
Florian Klink 2024-03-01 11:22:44 +02:00 committed by flokli
parent c9514b7c0c
commit b0e5a932ec
2 changed files with 0 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
tvix/docs/src/SUMMARY.md
View file

@ -2,7 +2,6 @@
# Tvix
- [Architecture & data flow](./architecture.md)
- [.drvPath inconsistencies](./differences-drv-paths.md)
# Nix
- [Specification of the Nix Language](./language-spec.md)

35
tvix/docs/src/differences-drv-paths.md
View file

@ -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