Command to remove lorri gc-roots

[dtzWill]

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?

[Profpatsch]

Since we’ve removed the .lorri directory from the project and are moving to hashed project paths as gcroot names, the disconnect is gonna be even bigger.

How about adding a plumbing command for now, lorri rm-gc-roots_ [--for <nix file>] (defaulting to .) until we get a better overview of what users need in practice?

[Gerschtli]

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:

$ lorri gc-roots --show
  1: /home/user/projects/example1
  2: /tmp/test-lorri1
  3: /home/user/projects/deprecated-project

$ lorri gc-roots --delete 3

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!

[Profpatsch]

This is a good candidate for contribution. Implementing the plumbing command I mentioned above should be fairly easy.

Any takers? :)

[hmenke]

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 shell.nix that it was created with

$ cat ~/.cache/lorri/gc_roots/<hash>/gc_root/ref
/path/to/shell.nix

In principle ref could also be a symlink to shell.nix but I don't know whether there are any adversary interactions with being a gcroot.