New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[V3] Garbage collection #1491

Merged
merged 4 commits into from Feb 29, 2016

Conversation

Projects
None yet
3 participants
@cdrnet
Member

cdrnet commented Feb 29, 2016

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.

@forki forki merged commit 40d4bd6 into fsprojects:v3 Feb 29, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@inosik

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Feb 29, 2016

Contributor

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.

Contributor

inosik commented Feb 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Feb 29, 2016

Member

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).

Member

forki commented Feb 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Feb 29, 2016

Contributor

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.

Contributor

inosik commented Feb 29, 2016

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.

@cdrnet cdrnet deleted the cdrnet:garbage-collection-v3 branch Mar 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment