Exposes the Value constructors, for use by other bindings like
nix-flake, which needs to construct e.g. a flake outputs Value.
See https://github.com/nixops4/nixops4/issues/25
> We have two related issues:
> A bunch of implementation details cannot be made private, since they must be used from one of the other crates (e.g. Values are defined in the value module but used from eval_state
> While we don't want users to need to use these features, it may be good to provide escape hatches so they can interface with the raw API if they need more control.
> Problem (1) has been solved in other crates with a __private module with #[doc(hidden)] set. See for instance:
I'm leaving docs turned on for (2). The issue has more thoughts about
alternatives.
(cherry picked from commit eb6744d1519febe5b6aa6233eb3f3e8a049f12d4)
This supports the more "advanced" `nix_eval_state_builder`, which
has more methods that we'll want to use.
(cherry picked from commit a96047000df6b7022d166a8c35bb6e3075e5eddb)
Note that `"auto"` holds a strange middle ground, reading
part of the general environment, but not all of it. It
ignores `NIX_REMOTE` and the `store` option.
(cherry picked from commit 7ba92a3793c2fe11938e802e6b61edee042b193a)
In the previous update commit, the Nix `cc.version` didn't match the
in-output directory name anymore, causing a build failure.
By asking GCC properly, we are robust against such discrepancies.
The script isn't great, relying on GCC "log" output specifics, but it
seems that the GCC output has been like this for a while, and the
lines before and after seem to be intentional about their purpose...
(cherry picked from commit 68f928555660cb914105b0ad668d6cadc25223e9)
... because it is. I had previously dismissed the comparatively
trivial unsafety of these functions, assuming the caller is
aware of the purpose of them and reasonably familiar with manual
memory management.
That would have been fine in an unsafe by default language like C++,
which Rust is not.
(cherry picked from commit b43455fdd0468f067741a79a7031ba2fa907f0eb)
Fixes https://github.com/nixops4/nixops4/issues/65,
possible undefined behavior.
This doesn't make the code nice wrt *const/*mut distinction, but
since we're not mutating it, this should be fine.
(cherry picked from commit 75d448aad923a5f835f0562400e223df43103ea4)
Fixes tests hanging. Before this commit:
nix build .#packages.x86_64-linux.nixops4-eval-release
See https://github.com/NixOS/nix/issues/11979
(cherry picked from commit 03af71f92488f2ee683565318f24afd3e3c001df)
Closes#31
A guard object is more capable, as it can be used in various
control flow and ownership schemes, including async code, but not
that it is not Send.
(cherry picked from commit f9aa5eab2561834c64ef9fe01979a91aee35848f)
They're somewhat safe to use on a different thread, but we don't need
to for now. By removing this, we'll be made aware as needed.
(cherry picked from commit 2e953d0a1268e2f19671fdbc9e721fc630ac346b)
A step toward handling the arrival of new data (stdin) with priority
over commands, avoiding roundtrips and re-evaluations.
(cherry picked from commit 8a2a5197886025caf35653001f76a4b209d8c9e4)
This allows cargo metadata to operate on it without adding the
source files to the build. (A choice which will save a few rebuilds
of the manual)
(cherry picked from commit 1779295f3e13cc15f8422d52a3753bb927ac8fa7)
It provides not so great values for some of the parameters, and we
don't really need its convenience.
(cherry picked from commit 52b7b58eb7fa96a265883cbf92e3a635735fe360)
