aboutsummaryrefslogtreecommitdiff
path: root/src/nix/dump-path.cc
AgeCommit message (Collapse)Author
2024-07-15libstore: rewrite narFromPath as generatoreldritch horrors
Change-Id: Ifa783c2c65c06ddd1d0212016d5bfd07666ea91c
2024-07-05libstore: convert dumpPath to a generatoreldritch horrors
Change-Id: Ic4cf5562504aa29130304469936f958c0426e5ef
2024-07-01tree-wide: unify progress bar inactive and paused statesAlois Wohlschlager
Previously, the progress bar had two subtly different states in which the bar would not actually render, both with their own shortcomings: inactive (which was irreversible) and paused (reversible, but swallowing logs). Furthermore, there was no way of resetting the statistics, so a very bad solution was implemented (243c0f18dae2a08ea0e46f7ff33277c63f7506d7) that would create a new logger for each line of the repl, leaking the previous one and discarding the value of printBuildLogs. Finally, if stderr was not attached to a TTY, the update thread was started even though the logger was not active, violating the invariant required by the destructor (which is not observed because the logger is leaked). In this commit, the two aforementioned states are unified into a single one, which can be exited again, correctly upholds the invariant that the update thread is only running while the progress bar is active, and does not swallow logs. The latter change in behavior is not expected to be a problems in the rare cases where the paused state was used before, since other loggers (like the simple one) don't exhibit it anyway. The startProgressBar/stopProgressBar API is removed due to being a footgun, and a new method for properly resetting the progress is added. Co-Authored-By: Qyriad <qyriad@qyriad.me> Change-Id: I2b7c3eb17d439cd0c16f7b896cfb61239ac7ff3a
2024-05-18nix cat/dump-path/key: stop progress bar before writeFullPuck Meerburg
These commands outputs data that may not end with a newline. This causes problems when the progress bar redraws, as that completely wipes the last line of output. As nix key generate-secret outputs a single line of text with no output, it shows up entirely blank, making it look like nothing happened. Fixes: https://git.lix.systems/lix-project/lix/issues/320 Change-Id: I5ac706d71d839b6dfa760b60a351414cd96297cf
2020-12-21Add 'nix store' NAR-related manpagesEelco Dolstra
2020-12-21Add 'nix nar' manpagesEelco Dolstra
2020-12-03Move most store-related commands to 'nix store'Eelco Dolstra
2020-12-03Add 'nix nar dump-path'Eelco Dolstra
This only differs from 'nix store dump-path' in that the path doesn't need to be a store path.
2020-10-06Remove static variable name clashesEelco Dolstra
This was useful for an experiment with building Nix as a single compilation unit. It's not very useful otherwise but also doesn't hurt...
2020-05-05nix --help: Group commandsEelco Dolstra
2019-12-10Make the Store API more type-safeEelco Dolstra
Most functions now take a StorePath argument rather than a Path (which is just an alias for std::string). The StorePath constructor ensures that the path is syntactically correct (i.e. it looks like <store-dir>/<base32-hash>-<name>). Similarly, functions like buildPaths() now take a StorePathWithOutputs, rather than abusing Path by adding a '!<outputs>' suffix. Note that the StorePath type is implemented in Rust. This involves some hackery to allow Rust values to be used directly in C++, via a helper type whose destructor calls the Rust type's drop() function. The main issue is the dynamic nature of C++ move semantics: after we have moved a Rust value, we should not call the drop function on the original value. So when we move a value, we set the original value to bitwise zero, and the destructor only calls drop() if the value is not bitwise zero. This should be sufficient for most types. Also lots of minor cleanups to the C++ API to make it more modern (e.g. using std::optional and std::string_view in some places).
2019-12-05Make subcommand construction in MultiCommand lazyEelco Dolstra
(cherry picked from commit a0de58f471c9087d8e6cc60a6078f9940a125b15)
2018-02-13Fix #1762Linus Heckemann
nix-store --export, nix-store --dump, and nix dump-path would previously fail silently if writing the data out failed, because a) FdSink::write ignored exceptions, and b) the commands relied on FdSink's destructor, which ignores exceptions, to flush the data out. This could cause rather opaque issues with installing nixos, because nix-store --export would happily proceed even if it couldn't write its data out (e.g. if nix-store --import on the other side of the pipe failed). This commit adds tests that expose these issues in the nix-store commands, and fixes them for all three.
2017-05-04nix dump-path: AddEelco Dolstra
This is primarily useful for extracting NARs from other stores (like binary caches), which "nix-store --dump" cannot do.