[V3] Garbage collection

[cdrnet]

PR #1482 but rebased on v3

I've started on a proposal how we could implement garbage collection to clean up packages no longer needed in the packages folder (and if possible the same for paket-files). Addresses #1416.

Since the packages folder is typically excluded from version control, we do not always have explicit information about a package being removed. What we do know is what packages are currently extracted in the packages folder, and what packages we actually expect to be there according to the lock file.

The proposed algorithm essentially goes through the subdirs of the packages folder, tries to imply group and package names, and drops all of these folders which we identify as a extracted package but are not known by the lock file (ignoring the version).

Questions:

• Is it safe to assume that the name of the extracted nuspec file matches the package id, or do we need to parse it to be sure? We could also interpret the folder name instead, which we do construct ourselves (with or without version).
• When/where would we want to do this? Should it be explicit? Only on demand? Currently it is rather aggressive: always after add, remove and install, unless --no-install is set, and always after restore. I expect this to be too aggressive in practice.

[inosik]

Is it really necessary to perform garbage collection that aggresively? I would prefer a paket gc command which one could issue when needed.

Git has a similar command, and performs GC from time to time itself. But it doesn't do so on every commit, rebase or whatever.

[forki]

Aggressive GC has some advantages when you do stuff like automatic tool
detection with fake. Do you have a specific issue in mind?
On Feb 29, 2016 8:42 PM, "Ilja Nosik" notifications@github.com wrote:

Is it really necessary to perform garbage collection that aggresively? I
would prefer a paket gc command which one could issue when needed.

Git has a similar command, and performs GC from time to time itself. But
it doesn't do so on every commit, rebase or whatever.

—
Reply to this email directly or view it on GitHub
#1491 (comment).

[inosik]

The first thing I have in mind is hopping between branches in Git repos. Maybe some more things which I'm not aware of right now.

I can't say much about issues with FAKE, I never noticed a significant performance impact.

But if I see it right, after this PR, Paket performs GC on every restore. Building in VS (or vanilla MSBuild) causes a restore for every project in a solution, if you do <Import Project="paket.targets" />. This might be a problem, I think.