Can I configure the location of the packages cache?

Is there any way to configure where packages are downloaded to and stored?

 

Please make this a priority. Ever since the introduction of the AssetStore developers have been requesting the ability to specify the location of asset package downloads to no avail. Personally I despise that assets ( data ) are 'polluting' my C drive, especially as its only a 256Mb SSD where the cost of space is at a premium. I already have over 4GB of asset store packages and no doubt the new package cache itself will soon balloon in file size too. Being able to specify it use a location on my 2TB other drive would be so much better.

Also in terms of features i'm wondering if a nice inbuilt back up system would be beneficial. I already make back ups of asset store packages by hand, and just completing an editor tool to do this automatically. Simple reason being that internet connection is not a given, even in the UK periodically I lose internet in off hours while the ISP does updates or housekeeping. In addition as much of my client work involves installing on-site and sometimes needing to make updates, having local back ups of older versions would be a nice safety net.

 

I think more global in nature, just so you can easily have backup of packages to take onsite, or be able revert to earlier versions etc. Again most beneficial when the internet might be unavailable, or as is often the case onsite can be intermittent or low bandwidth.

thanks.

 

Just found this as I was about to post the same request.
I think it is important to have a setting for where things are installed and downloaded. It especially applies for users with SSDs. This includes:

• Asset Store Local Packages: most people don't want that on C:, since some packages are huge (I've downloaded several GB in size) and it is not clear if these folders are safe to delete. Unity should consider a UI window for this, with the ability ton change the path and delete the cached packages from the UI.
• GI Cache.
• Package Manager packages. With multiple versions and 3rd party packages this will become important too, since we can't actually erase those like we could with Asset Store Packages Cache now.
• Place where new Unity Versions are installed with Unity Hub. Some versions we want in the default (preferred) path, presumably on C:, and some we don't. So, for example in my case, main project Unity version will go on C:, betas and legacy support versions will not. One solution would be to offer a list of install locations defined by the user, and for every new installation if there is more than one install location defined we should pick which one we want for this specific version. As it is today, it is actually more convenient to not use Unity Hub, since we can at least manually choose where things are installed.

 

I usually solve this with symlinks. Occasionally an app may have really terrible symlink support and screw everything up, but that’s pretty rare on macOS and Linux.

 

Moreover, this violates a software development tenet: Ideally, all code dependencies (with possible exception of platform/sdks) reside under source control for a given project. It is often the case that third party code is modified/fixed. It's ok to have a (optional) cache in the User's profile folder, but packages referenced by projects need to live under the project folder or at the least, we need an option to reference/download them there. If this isn't already implemented, please prioritize.

- appreciated

 

FWIW, SymLinks(Junctions, reparse points, etc.) can burn you. In particular, the new (forced) Windows Feature Pack updates are not simple in-place patches. They are clean Windows installations with user migration. Problem is that they often won't respect your junctions, particularly in Program Files and Program Files (x86) and other 'system' folders. Your content might be orphaned and junction obliterated, or Windows setup could fail completely (over and over and over and over). The constrained SSD C: problem is something the Windows and Visual Studio groups are aware of and they are taking some steps to try to change things, but it's not easy. So, be aware and careful if redirecting special system folders.

 

Maybe that's a problem unique to Windows. The other platforms supported by Unity treat symlinks as whatever they're pointing to.

 

It's not a problem with reparse point implementation on Windows. It functions similarly to other OS'es in that respect. Windows setup, during major feature upgrade (with user migration) deletes them and re-creates them as simple directories, because it is not checking if they are reparse points and doesn't re-create them as such.

 

It's the one and only reason we don't buy Unity... not even a safe workaround.

 

> In the short term, it will hopefully not be a major issue even with a small local HD since the number of new ackages and overall size is relatively small.

I've just checked and the cache directory was 2.5Gb

May I suggest this is now a high priority?

 

Mine is ~1Gb right now but I clear it up from time to time. My SSD is 128Gb, and there's usually only about 10Gb of free space available.

 

Hmm I missed this update, but glad I checked as my cache is now sitting at 7 GB!
Packages are 3.7 GB and npm is 3.3 GB.

Looks like i'm being punished for being early adopter and experimenting with new packages and that I regularly switch between multiple versions of Unity.

Edit:

So let me see if I've got this right.

I can delete both npm and package folders from the cache and face no consequences, other than Unity having to download and decompress packages on demand on a per project basis?

I can delete packages folder and will NOT lose any package data as the compressed versions live in npm folder. Thus there is no risk and only downside is that Unity will have to decompress packages on demand per project.


As for the future, the explosive growth of the cache would indicate that Unity needs to take steps to address the problem. Maybe some efforts have already been made, but as of 2018.4 I couldn't find any means to clear the cache at all, let alone in an intelligent way.

What I think we need

A means of clearing the cache from within Unity ( preferences ) with options to

• Clear all - explain danger of losing npm versions.
• Clear packages only - and explain there is no danger of data loss.

Ideally we'd then have filters on top of this to

• Clear by date.
• Clear non-verified packages if a verified package exist.
• Clear oldest previews.

In addition it would be great to add additional support along the lines of adding a file to the cache that will track package usage by project name. This would provide a means for users to examine on a per package version basis the frequency of its use and which specific projects. That way they can be more informed in terms of deciding whether to delete npm packages or not.

Thinking about it perhaps working in reverse of the last paragraph might be better, that in a project you can via the package manager mark all the used packages as 'essential'. This will then store this information in a database that all the packages in this project must be kept and never removed via 'Cache clearing'. The database entry will be kept in sync with the project so it will track changes to packages or versions used.

 

--------------------------------------------------
Has this been fixed? i have 0 bytes left on my c:/
Litterally cant work on the project now

 

Heya just wanted to add to this: Now that the package manager also downloads assetstore purchases there should definitely be some way to change this folder's location via UI. Just got confused for about 2h because I couldn't figure out why Unity wouldn't let me extract a package (C:// volume full)

 

Just FYI, I think I filed a report for the issue like 6 years ago; and I was told "we are looking into it".

Not sure what is so hard in implementing a simple path string for the packages; I can have projects saved wherever I want. and same for my GI cache, so the same should go for packages from the store. I find excessive to ask me to create a symlink to another drive, just because there is no option to specify the packages cache, except in your main drive.

It is one of those low-hanging fruits that takes very little to be put in place, and it has quite a large impact for many users that like to work offline and have their whole asset library with them.
Also imagine the case where you replace your main drive... you need to download everything again, while you could simply point Unity to the external drive location.

My assets library from the store is quite large; not sure about everyone else, so that would really be a useful thing to have.

 

Just adding my "Yes please" to this. Currently fighting my UserData Partition because it's years old and getting too small.

 

The solution for now is to use Symbolic Links. They are like shortcuts, except windows recognises them as the actual folder.

Get this shell extension. The website looks like it's from 1998, so you know the software works.

1. Close Unity/Hub.
2. Create two folders on your desired hard drive, such as

   E:\Unity\AppDataLocal

   and

   AppDataRoaming

   . Note: Some unity folders have stupidly long names, so make this folder near your root.
   
3. Cut + Paste the Unity folder from

   C:\Users\_Username_\AppData\Local\Unity

   to

   E:\Unity\AppDataLocal

   .
4. When finished, right-click-drag the Unity folder back into

   C:\Users\_Username_\AppData\Local

   and choose

   Drop Here > Symbolic Link

   . Note: You will need two windows open for this, or, alternatively, I think you can cut+paste the symbolic link anywhere you want after creation.

Repeat for the stuff in

C:\Users\_Username_\AppData\Roaming\Unity

.

Now you have saved 7GB+

Other spam you might want to move:

AppData\Local\unityhub-updater

AppData\Roaming\UnityHub

AppData\Roaming\Unity Hub

(with a space this time).

 

Hi, new unity user here. I'd like to throw my hat in the ring also, as saying this is a desperately needed feature. It's pretty standard to be able to tell software where to store things, and much like everyone else here, I use a small SSD primary (250 gb) for the absolutely critical stuff and a massive platter drive (4 tb) for holding large volumes of data where r/w speed is not critical.

It's more than a little irritating that Unity is thumbing its nose at me and using my primary drive for this (which is extremely space-hungry), when I've specifically told Unity to install itself and dump its builds onto that large external drive.

This needs addressed, and I'm very concerned that users have been unsuccessful in persuading your team to implement such a trivial request for such a standard option after more than two years.

 

Welcome to Unity development! This will not be the last time you say these words.

 

Unity packages are already eating up 8 gb on my primary drive and I'd like to remove some of the packages. Unfortunately, the package manager (which should just be called a package installer, because you can't actually manage anything) doesn't allow you to delete packages.

The manual is not helpful, it only tells you how to remove a reference to a package from a project. I can't even delete specific packages off my hard drive to juggle packages until (if?) they ever get around to fixing this.

It doesn't appear the development team is paying attention to this issue.

 

@Uthgaard I believe it's always safe to delete the entire directory as it's just a cache which Unity will recreate if needed.

Not that there's any official word on this so we're just expected to guess how to fix problems caused by full system drives...

 

still a stilly issue in unity 2020.2 well infact the entire package manager is broken in 2020.x
Such Bs, that the large packages i have to move them manually in windows after download to free C: from the Unity Bs.

 

I cannot import or use a $130 asset package, because it is 12 gb, and I have 20 available on my primary SSD. Even if it does download (which is a nightmare in itself because the package manager doesn't support resuming downloads) it attempts to immediately extract it on the spot, which is impossible so it fails. The download uses a .tmp file format that is incomplete and unsalvageable even if the extension is changed.

The asset store does not give me the ability to simply direct download the asset to a location of my choosing (like my 4 tb working drive with tons of space available, where Unity is actually installed). This option would be a reasonable stopgap, if you really can't be bothered to fix your package manager.

I am forced to use this buggy package manager (which is incapable of actually managing anything). This means that I cannot access the package, and have no possible workarounds.

Unity? Anyone out there got their ears on? Or are you really okay with charging people money for this kind of experience?

 

Found that topic searching for solution. I have SSD partition C with size 256 GB - mostly for system and some important programs. Also installed unity there. But I found out that something is "eating" my free space there, so that drive is practically full now. I started searching and unfortunetly found out that unity "eats", just in AppData - almost 20 GB -> 19,7 GB (9.59GB in "Roaming", 5.40GO in "LocalLow and 4.70GB in "Local").
I remember cleaning that folders out of packages at middle of 2020 and it was around 35 - 40 GB.
Most of that stuff are packages.
We really need feature letting us to set directory for packages "cache"...

 

Its not like I'm saying anything new but yeah, this is fairly ridiculous, 16gb has been taken up by packages in my AppDataLocal alone and half of the packages haven't even been used in my projects for months, there are a couple packs I purchased because they had some neat stuff and I'm just finding out they've been sitting there, on my C drive, unused, for months??? testing the Symbolic link thing now but really should I have to? This issue has been known for years, at least have a fix implemented for 2020 LTS

 

I have the same problem than most of the people here, I'm trying to import a big paid package and it wont works because Unity is trying to decompress it on my small SSD.

I hope this will be fixed soon, but I cannot help doubting it.

This kind of unfixed problems that last for years is ruining Unity's reputation. It is one of the main arguments of UE users, and I can't prove them wrong. Especially about such a trivial functionality.

 

How has this issue not been resolved in 3 years? For the love of God, it can't be that difficult.

 

It's not difficult, the problem is that Unity has terrible organization/management and a bad system for prioritizing tasks.

 

Just to highlight how bad this can get.

If anyone tries the new Automotive HDR template - wave goodbye to 3.5gb of your system drive.

That was enough to crash my machine. Thanks Unity.

It's a daily battle to keep my Windows drive clear. I've done all the obvious stuff (User folders moved, most apps installed elsewhere). The next step is a fragile set of symlinks but I'm wary of going down that path. This is partly Microsoft's fault but every app vendor needs to play it's part in respecting our drive space. Small SSDs for the boot drive are the norm and have been for many years now.

 

> despite the idea being a good one.

It's not a "good idea" - it's a request to please not break my computer.

You can't be releasing 3gb templates and huge packages and at the same time claim this is a "nice to have".

Most PCs come with small system drives. Therefore you can't just treat it as unlimited space. Can you escalate this please?

 

This is truely bizarre. Such a feature is not simply 'nice to have' its proving to be essential as more and more developers are finding their C drives filled up due to this decision.

Perhaps it would help to explain why having a custom folder locations is such a difficult modification. Though honestly I can't think of a single reason, its not like packages require the security of being on the C drive in the appData folder.

 

I'm glad somebody bothered to check on it, because some time ago I remember I wanted to try Unity out and I couldn't remember why I dropped it. This whole thing made me remember. I mean if it's both easy to implement and very bothersome to your customers, to the point where they could give up, why is it so low on the list of priorities?

I actually tried the symlinks method and it works great. It's just a shame I had to do it in the first place.

 

Just to echo previous comments, this really needs sorting, guys. It's annoying enough that every project I start ends up having 600MB+ of library assets, but at least I can control where I put my projects.

For now I've done a combination of the link from ok_compute: https://docs.unity3d.com/Manual/upm-cache.html
and this: https://www.reddit.com/r/Unity3D/comments/79gb6q/changing_the_download_location_of_unity_asset/ to junction away my oversized \AppData\Roaming\Unity\Asset Store-5.x folder

Cheers,
Chris

 

Is the voting a reliable metric? I've never voted on a feature. It's certainly a poor measure of things I find to be important. I'm more likely to complain here, on Twitter or just swear at my computer and wonder if I shouldn't be looking into Unreal again.

Isnt there a point where something is so obviously an oversight or poor design decision that it's just worth fixing?

 

"Hello Unity users. We've heard your complaints that the Unity editor cannot be closed after you open it. We understand that being able to close the editor is an important feature for many of you. We've opened up voting on this issue. In six months we'll check back on it, and if enough of you voted, we'll pretend we've started working on it. If you plebs are lucky, you'll see this feature sometime around 2026-2028.

In the meantime, as a workaround, you can use two computers: one with Unity open, and one without Unity installed. You can switch between computers depending on whether you want Unity closed or open at a given time."

 

Yes - I understand why you want to use it. I'm just questioning whether it provides useful data.

 

Not sure why you need an issue tracker for this, the various voting systems Unity have implemented over the last decade or longer have rarely worked in favour of your customers.

Of greater concern though to me is that this issue ties both UPM and Asset Store configurable locations together!

I can live with not having a configurable Asset Store location ( sort of - see below ) but not UPM! As has been outlined very well in this thread UPM is far more difficult to control for a user for many reasons. Packages may simply be too large to fit on their c drive and we can't easily remove packages as we have no idea which ones and which versions are in use by which project. So even if you do delete them, opening up a few projects will most likely result in many being re-downloaded! Worse UPM just keeps growing regardless every time you open a new Unity project with a new version of Unity as updated packages are downloaded!

It would be unfortunate for UPM configurable location to get knocked back because someone tied it together with Asset Store location, something that has been requests since the inception of the asset store more than a decade ago - yet NEVER implemented!

Honestly I just do not understand the resistance to such a feature or why it is apparently so difficult to implement. What is the challenge in allowing users to configure where packages are downloaded to?

With regards to the Asset store, I gave up waiting for Unity to do something about it, and just wrote my own editor manager that is faster to use than either the asset store browser or the new attempt of 'assets in package Manager'. It allows me to quickly find and import an asset and I can easily move assets between the default location and my own archive on another disk. Sadly this is not a viable solution for UPM for the same reasons listed above.