2022-12-08 22:19:22 +01:00
|
|
|
[package]
|
|
|
|
|
name = "tvix-cli"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
edition = "2021"
|
|
|
|
|
|
2022-12-12 19:40:29 +01:00
|
|
|
[[bin]]
|
|
|
|
|
name = "tvix"
|
|
|
|
|
path = "src/main.rs"
|
|
|
|
|
|
2022-12-08 22:19:22 +01:00
|
|
|
[dependencies]
|
2023-01-31 14:45:42 +01:00
|
|
|
nix-compat = { path = "../nix-compat" }
|
2024-01-16 12:14:07 +01:00
|
|
|
tvix-build = { path = "../build" }
|
2023-09-21 21:32:44 +02:00
|
|
|
tvix-castore = { path = "../castore" }
|
2023-09-26 10:09:15 +02:00
|
|
|
tvix-store = { path = "../store", default-features = false, features = []}
|
2022-12-08 22:19:22 +01:00
|
|
|
tvix-eval = { path = "../eval" }
|
2023-11-03 12:34:37 +01:00
|
|
|
tvix-glue = { path = "../glue" }
|
2023-09-02 20:16:35 +02:00
|
|
|
bytes = "1.4.0"
|
2022-12-16 12:54:22 +01:00
|
|
|
clap = { version = "4.0", features = ["derive", "env"] }
|
2022-12-08 22:19:22 +01:00
|
|
|
dirs = "4.0.0"
|
2023-09-02 20:16:35 +02:00
|
|
|
rustyline = "10.0.0"
|
2023-01-26 23:42:10 +01:00
|
|
|
thiserror = "1.0.38"
|
refactor(tvix/store/blobsvc): make BlobStore async
We previously kept the trait of a BlobService sync.
This however had some annoying consequences:
- It became more and more complicated to track when we're in a context
with an async runtime in the context or not, producing bugs like
https://b.tvl.fyi/issues/304
- The sync trait shielded away async clients from async worloads,
requiring manual block_on code inside the gRPC client code, and
spawn_blocking calls in consumers of the trait, even if they were
async (like the gRPC server)
- We had to write our own custom glue code (SyncReadIntoAsyncRead)
to convert a sync io::Read into a tokio::io::AsyncRead, which already
existed in tokio internally, but upstream ia hesitant to expose.
This now makes the BlobService trait async (via the async_trait macro,
like we already do in various gRPC parts), and replaces the sync readers
and writers with their async counterparts.
Tests interacting with a BlobService now need to have an async runtime
available, the easiest way for this is to mark the test functions
with the tokio::test macro, allowing us to directly .await in the test
function.
In places where we don't have an async runtime available from context
(like tvix-cli), we can pass one down explicitly.
Now that we don't provide a sync interface anymore, the (sync) FUSE
library now holds a pointer to a tokio runtime handle, and needs to at
least have 2 threads available when talking to a blob service (which is
why some of the tests now use the multi_thread flavor).
The FUSE tests got a bit more verbose, as we couldn't use the
setup_and_mount function accepting a callback anymore. We can hopefully
move some of the test fixture setup to rstest in the future to make this
less repetitive.
Co-Authored-By: Connor Brewster <cbrewster@hey.com>
Change-Id: Ia0501b606e32c852d0108de9c9016b21c94a3c05
Reviewed-on: https://cl.tvl.fyi/c/depot/+/9329
Reviewed-by: Connor Brewster <cbrewster@hey.com>
Tested-by: BuildkiteCI
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
2023-09-13 14:20:21 +02:00
|
|
|
tokio = "1.28.0"
|
2024-02-17 11:33:32 +01:00
|
|
|
tracing = { version = "0.1.37", features = ["max_level_debug", "release_max_level_info"] }
|
2024-02-14 02:56:31 +01:00
|
|
|
tracing-subscriber = { version = "0.3.16", features = ["json"] }
|
refactor(tvix/cli): use Wu-Manber string scanning for drv references
Switch out the string-scanning algorithm used in the reference scanner.
The construction of aho-corasick automata made up the vast majority of
runtime when evaluating nixpkgs previously. While the actual scanning
with a constructed automaton is relatively fast, we almost never scan
for the same set of strings twice and the cost is not worth it.
An algorithm that better matches our needs is the Wu-Manber multiple
string match algorithm, which works efficiently on *long* and *random*
strings of the *same length*, which describes store paths (up to their
hash component).
This switches the refscanner crate to a Rust implementation[0][1] of
this algorithm.
This has several implications:
1. This crate does not provide a way to scan streams. I'm not sure if
this is an inherent problem with the algorithm (probably not, but
it would need buffering). Either way, related functions and
tests (which were actually unused) have been removed.
2. All strings need to be of the same length. For this reason, we
truncate the known paths after their hash part (they are still
unique, of course).
3. Passing an empty set of matches, or a match that is shorter than
the length of a store path, causes the crate to panic. We safeguard
against this by completely skipping the refscanning if there are no
known paths (i.e. when evaluating the first derivation of an eval),
and by bailing out of scanning a string that is shorter than a
store path.
On the upside, this reduces overall runtime to less 1/5 of what it was
before when evaluating `pkgs.stdenv.drvPath`.
[0]: Frankly, it's a random, research-grade MIT-licensed
crate that I found on Github:
https://github.com/jneem/wu-manber
[1]: We probably want to rewrite or at least fork the above crate, and
add things like a three-byte wide scanner. Evaluating large
portions of nixpkgs can easily lead to more than 65k derivations
being scanned for.
Change-Id: I08926778e1e5d5a87fc9ac26e0437aed8bbd9eb0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8017
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
2023-02-02 13:51:59 +01:00
|
|
|
|
|
|
|
|
[dependencies.wu-manber]
|
2023-02-04 10:05:13 +01:00
|
|
|
git = "https://github.com/tvlfyi/wu-manber.git"
|
2023-10-21 19:52:22 +02:00
|
|
|
|
|
|
|
|
[dev-dependencies]
|
2024-01-05 15:12:35 +01:00
|
|
|
test-case = "3.3.1"
|