-
Notifications
You must be signed in to change notification settings - Fork 69
Command to remove lorri gc-roots #16
Comments
Since we’ve removed the How about adding a plumbing command for now, |
I would like to give my point of view to this issue: It would be a nice feature if lorri could show an overview of all current used gc roots with the ability to select one or more and remove these gc roots. For example:
My use case is that I want to remove gc roots of testing environments or deprecated projects I used, so an "overview" command is definitely necessary in my opinion. I would love to help with this kind of feature, once the cli design is set. BTW: Very nice work with this project! |
This is a good candidate for contribution. Implementing the plumbing command I mentioned above should be fairly easy. Any takers? :) |
For me personally it would be sufficient if lorri just kept a reference to the source next to the gcroot. Then I can use a normal bash script to produce a list of used and unused gcroots. For that I guess adding something like this would be the way to go? (No idea whether that compiles, I don't really speak Rust) --- a/src/project.rs
+++ b/src/project.rs
@@ -34,14 +34,20 @@ impl Project {
gc_root_dir: &Path,
cas: ContentAddressable,
) -> std::io::Result<Project> {
+ let nix_file_path = nix_file.as_path().as_os_str().as_bytes();
+
let hash = format!(
"{:x}",
- md5::compute(nix_file.as_path().as_os_str().as_bytes())
+ md5::compute(nix_file_path)
);
- let project_gc_root = gc_root_dir.join(&hash).join("gc_root");
+ let project_dir = gc_root_dir.join(&hash);
+ let project_gc_root = project_dir.join("gc_root");
std::fs::create_dir_all(&project_gc_root)?;
+ let mut file = File::create(project_dir.join("ref"))?;
+ file.write_all(nix_file_path)?;
+
Ok(Project {
nix_file,
gc_root_path: project_gc_root, For each new gcroot this would create a file which contains the path to the $ cat ~/.cache/lorri/gc_roots/<hash>/gc_root/ref
/path/to/shell.nix In principle |
Currently it is not possible to determine whether a gc_root is used or not because the path is a hash of the filename that it was created from. When the source is deleted, the gc_root will remain forever unable to be garbage collected. Once the user accumulates several projects, it is also very hard to tell which gc_root belongs to which project, because there is no bidirectional mapping. In target#16 it was suggested to add a subcommand to lorri that will automatically remove unused gc_roots, however, without a mapping from the name of the gc_root back to the location of the source this is impossible. This commit addresses this issue in parts by creating a file with the name `ref' next to the gc_root which will simply contain the full path of the shell file it was originally created for. In the future this information could be used to automatically detect and garbage-collect unused gc_roots, but even without that it will enable the user to write a simple shell script which picks up each `ref' and checks whether the file inside exists. Another possibility instead of using a file containing the path name would be to make `ref' a symlink to the shell file. When the symlink is broken, the gc_root is unused. However, that might pose a problem for users using lorri through WSL on Windows, because Windows filesystems don't support symlinks. I'm unsure whether that is a concern, but I opted for the safer option of just a plain file.
So this is really a Nix issue (how to triage gc roots across a system?), but now that I am spawning lorri's everywhere to watch my things I'm finding that managing my gcroots is a bit of a pain. Firstly looking up the paths corresponding to a given project (or the other way around) is not rocket science but introduces enough of a disconnect to cause friction. Introducing 3 gcroots per project is also a factor,
making a list of gc roots seem more intimidating than it really is :).
I don't mean to complain, but this seems like something that could have a good solution (perhaps) as part of lorri and for everyone's benefit.
Any plans/thoughts on this front?
I suppose a basic "here is the gc roots for this project" as entries in
lorri info
would be a start,and perhaps a simple "clear the eval cache" (phrased better) subcommand?
The text was updated successfully, but these errors were encountered: