Manifests are stored with their corresponding scattered environments, not in a centralized place, and you probably don’t want to delete everything next to a manifest file, like a carefully curated Project.toml.
Yes, so moving the manifest or its enclosing folder where Pkg.gc can’t find it is just as good as deleting it. PkgCleanup.jl is nice that it just makes Pkg untrack instead of needing to move or delete manifests. Keeping an inactive manifest is necessary for instantiate-ing the exact environment down the line, if exact reproducibility is the goal. Sometimes you only need the project file because you worked out a good [compat] and can accept patches.
I do think we should really be a little more aggressive by default about cleaning things up. There’s a delay mechanism we built into Pkg.gc where instead of immediately deleting anything unreachable, it puts it in an “orphans” file and then deletes it if it’s been an orphan for long enough. The idea was that we didn’t want to flap back and forth between deleting and then reinstalling the same thing, but I don’t think that’s really an issue. Maybe when we run Pkg.gc automatically we could still do that, but I definitely think that when someone does an explicit Pkg.gc call (or >pkg gc) we should delete anything unused.
We should also really prompt to “deactivate” manifests that haven’t been used in a certain amount of time. Or maybe even do it automatically. Having local manifests all over the place is a big part of why people’s depots get so big.
Another thing that piles up and doesn’t get cleaned are pre-compiled caches. I often have more than one REPL opened (plus the one of VSC) that for one reason or another (I’m talking to you, debugger) need to restart. Every time I restart there will be a recompilation of the code I’m writing and new dll gets created. The compiled directory with the caches easily grows to 1 GB and the only way to clean this is a manual delete.