You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question: Can packages be stored in one global machine folder instead of a packages folder per project? #2141
Don't think that this is on the roadmap. There's many reasons why Paket doesn't do this. What's the reason why you'd like this? Paket does maintain a cache of all packages to reduce network traffic.
@isaacabraham For each project that I create that uses some very popular nuget packages (example FsLab), I don't want to have the packages stored in each of the project's packages folder. Its a waste of disk space.
I'm sure others can correct me but I think the basic principle with Paket here is: disk space is cheap (maybe not so much with .net core....) but there's no great way for knowing where some global store of packages might be - much simpler to have copies per project. The same way that there's no more GAC really.
I'm not sure, I agree completely. Disk space certainly would be cheap or perhaps abundant on a non-Developer machine (i.e. server environments with network storage) but developers mostly use laptops or computers that have only local hard drives attached (i.e. non-expandable, although you may argue that you could add an external USB storage but at work places, it is not a common option at least in most of the places I worked.
In my case, I have a work laptop that has 500 GB SSD. Like a typical developer, I have a lot of tools, IDEs, VM (hyperv and virtualbox hard drives) instances and other applications installed. Not to mention work related stuff. Sooner than later you run into situations where you will have to periodically make room for new stuff.
For example, for FSharp data scripting, I installed FsLab nuget pacakge alone (I'm using Atom editor), and it downloaded ~430 MB to the packages folder. I wouldn't want that to be duplicated across the projects on my Dev laptop.
This would be easily doable with symlinks on a unix/windows-10-greater-than-build-14972 environment, I would think. We already have the package cache and could use symlinks instead of copies?
For windows, the mentioned build number allows unprivileged symlink creation, though we could maybe do something like detecting if we were running as an administrator to determine if we could use symlinks for previous versions of windows.
For windows, the mentioned build number allows unprivileged symlink creation, though we could maybe do something like detecting if we were running as an administrator to determine if we could use symlinks for previous versions of windows.
Excuse my ignorance, but would directory junctions already do the trick? Scoop, a CLI installer I use, creates junctions for apps, which point to the latest installed version, so one doesn't need to update paths in case of an update. I use Scoop on my computer at work, and we don't have the rights to create symlinks, but junctions seem to work without any problems so far.
I think it would be nice if Paket would create junctions/symlinks in the packages/ directory, which point to the unpacked package directory in the cache folder.
Please correct me if I'm wrong, but doesn't the new dotnet CLI (and nuget) store the packages in a central location, albeit per user, (C:\Users\[User]\.nuget\packages). I wonder what technique is employed there.
Can anyone give an workaround advice to reduce space used by packages folder or how to make it shared? Is symlinks/junctions approach worked? @stanuku, do you found any workaround?
Activity
isaacabraham commentedon Feb 15, 2017
Don't think that this is on the roadmap. There's many reasons why Paket doesn't do this. What's the reason why you'd like this? Paket does maintain a cache of all packages to reduce network traffic.
stanuku commentedon Feb 15, 2017
@isaacabraham For each project that I create that uses some very popular nuget packages (example FsLab), I don't want to have the packages stored in each of the project's packages folder. Its a waste of disk space.
isaacabraham commentedon Feb 15, 2017
I'm sure others can correct me but I think the basic principle with Paket here is: disk space is cheap (maybe not so much with .net core....) but there's no great way for knowing where some global store of packages might be - much simpler to have copies per project. The same way that there's no more GAC really.
stanuku commentedon Feb 15, 2017
I'm not sure, I agree completely. Disk space certainly would be cheap or perhaps abundant on a non-Developer machine (i.e. server environments with network storage) but developers mostly use laptops or computers that have only local hard drives attached (i.e. non-expandable, although you may argue that you could add an external USB storage but at work places, it is not a common option at least in most of the places I worked.
In my case, I have a work laptop that has 500 GB SSD. Like a typical developer, I have a lot of tools, IDEs, VM (hyperv and virtualbox hard drives) instances and other applications installed. Not to mention work related stuff. Sooner than later you run into situations where you will have to periodically make room for new stuff.
For example, for FSharp data scripting, I installed FsLab nuget pacakge alone (I'm using Atom editor), and it downloaded ~430 MB to the packages folder. I wouldn't want that to be duplicated across the projects on my Dev laptop.
baronfel commentedon Feb 15, 2017
This would be easily doable with symlinks on a unix/windows-10-greater-than-build-14972 environment, I would think. We already have the package cache and could use symlinks instead of copies?
For windows, the mentioned build number allows unprivileged symlink creation, though we could maybe do something like detecting if we were running as an administrator to determine if we could use symlinks for previous versions of windows.
forki commentedon Feb 16, 2017
inosik commentedon Feb 16, 2017
Excuse my ignorance, but would directory junctions already do the trick? Scoop, a CLI installer I use, creates junctions for apps, which point to the latest installed version, so one doesn't need to update paths in case of an update. I use Scoop on my computer at work, and we don't have the rights to create symlinks, but junctions seem to work without any problems so far.
I think it would be nice if Paket would create junctions/symlinks in the
packages/directory, which point to the unpacked package directory in the cache folder.inosik commentedon Feb 16, 2017
If we're going to implement this, it should be possible to opt out, in case this causes side effects.
forki commentedon Feb 16, 2017
It should be disabled by default for a while until we feel comfortable enough.
stanuku commentedon Feb 16, 2017
Please correct me if I'm wrong, but doesn't the new dotnet CLI (and nuget) store the packages in a central location, albeit per user, (C:\Users\[User]\.nuget\packages). I wonder what technique is employed there.
forki commentedon Feb 16, 2017
yes it does. which is baaaad for thinks like scripts where you want to reference stable paths
stanuku commentedon Feb 16, 2017
Agree. I believe, you could override the default with a config setting in the nuget.config.
maestrow commentedon Jun 4, 2017
Can anyone give an workaround advice to reduce space used by packages folder or how to make it shared? Is symlinks/junctions approach worked? @stanuku, do you found any workaround?
stanuku commentedon Jun 5, 2017
@maestrow No I haven't, sorry.
matthid commentedon Aug 20, 2017
This will be available soon and is tracked in #2638, please test the PR (or soonish alpha). If it doesn't fix the problem let us know.