TVL depot development (mail to depot@tvl.su)
 help / color / mirror / code / Atom feed
From: Vincent Ambo <mail@tazj•in>
To: Adam Joseph <adam@westernsemico•com>, depot@tvl.su
Cc: Lukas Epple <sternenseemann@systemli•org>,
	Griffin Smith <grfn@gws•fyi>,  Florian Klink <flokli@flokli•de>
Subject: [tvix] string contexts vs. reference scanning
Date: Mon, 9 Jan 2023 14:07:58 -0800	[thread overview]
Message-ID: <CANHrikpS8YXVPUzmqE-yWBse85j3RRjTu0tR4yg9Cqz89CpeNw@mail.gmail.com> (raw)
In-Reply-To: <20221202152213.3a59e629@ostraka>

[this mail thread is started out of another mail conversation]

We are currently implementing `builtins.derivationStrict`, which
translates the string context in evaluator values to the inputDrvs and
inputSrcs fields in a derivation struct in C++ Nix.

Florian and I have been "documenting"[0] our understanding of the code
that does this in Nix as we go along.

As amjoseph has previously said, string contexts are likely unnecessary:

Adam Joseph <adam@westernsemico•com> writes:
> Related to that second reason: I've written a tool (using the awesome
> libnixstore crate) that calculates drv.inputDrvs using scanForReferences
> instead of string contexts, and compares the calculated results to what
> cppnix produced. I ran it on the 144,586 derivations in my buildfarm's
> store, and (after fixing a lot of bugs in my scanner) there was only a
> single disagreement in the entire store, which IMHO is better described
> as a revealed bug in nixpkgs

Because of this, We plan to use reference scanning over derivation input
attributes instead of string contexts, but may need to address the
problem of implementing unsafeDiscardStringContext to support certain
use cases[1].

Adam, would you be up for pushing a WIP CL (or a commit straight to
//users/amjoseph!) with the scanner you've written (and esp. with your
bugfixes!) that we could then figure out how to integrate? It might help
us avoid some overhead of running into the same bugs again :)

Any other input people might have on string contexts is also welcome!

[0]: https://github.com/tvlfyi/nix/commit/wtf-are-contexts

[1]: I'm not actually sure about this. It's possible that all these
use-cases that exist right now (e.g. string context discarding in TVL's
:llama: step) actually go away with the Tvix model of starting builds
immediately, but strongly ordered. Thoughts?

       reply	other threads:[~2023-01-09 22:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CANHrikrEDPkH1raGDGAGETeATrWOJ=sBQCUXr6=pHJm1ajbd0A@mail.gmail.com>
     [not found] ` <20221202152213.3a59e629@ostraka>
2023-01-09 22:07   ` Vincent Ambo [this message]
2023-01-11 11:49     ` sterni
2023-01-11 12:20       ` Vincent Ambo
2023-03-16  9:41     ` Vincent Ambo
2023-03-16 12:00       ` Florian Klink
2023-01-10 20:20   ` reference-scanning inputDrvs/inputSrcs Adam Joseph
2023-01-10 20:48     ` Vincent Ambo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANHrikpS8YXVPUzmqE-yWBse85j3RRjTu0tR4yg9Cqz89CpeNw@mail.gmail.com \
    --to=mail@tazj$(echo .)in \
    --cc=adam@westernsemico$(echo .)com \
    --cc=depot@tvl.su \
    --cc=flokli@flokli$(echo .)de \
    --cc=grfn@gws$(echo .)fyi \
    --cc=sternenseemann@systemli$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://code.tvl.fyi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).