Question: Can packages be stored in one global machine folder instead of a packages folder per project?

[stanuku]

I wasn't sure if this is the right place to ask a question. Please let me know otherwise.

Thanks

[isaacabraham]

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]

@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]

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]

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]

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]

Symlinks would be a nice feature. Am 15.02.2017 22:41 schrieb "Chet Husk" <notifications@github.com>:

…

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? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCOh96Wc_qS7w1Fte_RTXDgn3RB_ks5rc3EmgaJpZM4MCIot> .

[inosik]

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.

[inosik]

If we're going to implement this, it should be possible to opt out, in case this causes side effects.

[forki]

It should be disabled by default for a while until we feel comfortable enough.

[stanuku]

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]

yes it does. which is baaaad for thinks like scripts where you want to reference stable paths

[stanuku]

Agree. I believe, you could override the default with a config setting in the nuget.config.

[maestrow]

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]

@maestrow No I haven't, sorry.

[matthid]

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.