Getting weird package manager error when attempting to install OpenVR package from GitHub

Was able to reproduce in 2019.3.15f1 and 2020.1.0b12:

"Package Metadata store error. Check if there are any other errors in the console and make sure they are corrected before trying again."

Everything works normally until I try loading this particular package and then it starts throwing this error once every 5 mins or so...

 

+1, this freezes development for 30 seconds every 5 minutes, Unity please fix this, bug report submitted

 

+1 3.2.12

 

3.1.12

 

Cool, I was sure I was doing something wrong with my .git PATH config or something.

 

This issue is plaguing my project too, 3.2.12 version which is verified causes it. Rolling back to preview package 3.2.10 fixes it for us.

 

solved for me with 3.2.10

 

Hi, is there some way to pin/lock a package version in Unity in the meantime? I've been hitting this issue for the last week or so and it works to revert to 3.2.10 but something (seemingly randomly) keeps triggering an automatic update back to 3.2.12. I have a packages-lock.json file which contains:

"com.unity.xr.management": {
"version": "3.2.10",
"depth": 0,
"source": "registry",
"dependencies": {
"com.unity.xr.legacyinputhelpers": "2.1.2",
"com.unity.subsystemregistration": "1.0.6"
},
"url": "https://packages.unity.com"
},

but that doesn't seem to stop this package from being periodically updated by something.

 

To clarify a bit more; I'm using the package manager to repeatedly manually downgrade the package and that edits the manifest.json so I have a line like:

"com.unity.xr.management": "3.2.10",

If the package manager itself is letting me downgrade then I presume I'm not breaking the dependency requirements for anything else?, so I don't know what is asserting that it requires 3.2.12.

I haven't actually modified the lock file by hand at all, that's just what the package manager has written. I haven't found any documentation for the lock file schema so far so I haven't tried editing it. From inspection it looks like it's already trying to lock the version I want though, so I don't really understand why it keeps reverting.

If there's something invalid about downgrading the 3.2.10 because something else depends on a newer version of xr.management then shouldn't the package manager stop me from downgrading it?

 

I'm currently only using the Oculus XR plugin package (1.3.3) which depends on xr.management 3.0.6 so I guess I shouldn't need to downgrade it. Assuming that there are no version conflicts going on (I'm pretty certain none of my packages depend on xr.management 3.2.12) is there some way I can edit the lock file to pin the version. It seems like there's something that basically periodically (or rather it's done off the back of a script compilation hook) checks for updates and auto pulls in the latest xr.management plugin.

Here's my full manifest.json: https://pastebin.com/zWhrrieM
and here's my packages-lock.json: https://pastebin.com/iZEpqrVY
I'm using the package manager to do the downgrading and haven't edited the lock file so far.

 

Sorry, I meant to write "1.3.4" for the Oculus XR plugin package version, which depends on xr.management 3.0.6. This is the relevant section from my packages-lock.json:

"com.unity.xr.oculus": {
"version": "1.3.4",
"depth": 0,
"source": "registry",
"dependencies": {
"com.unity.xr.management": "3.0.6",
"com.unity.ugui": "1.0.0"
},
"url": "https://packages.unity.com"
},

 

I'm not sure I follow what that might change? To clarify I can downgrade the package and I can shutdown Unity so at that point what would the difference be if I hand edit the manifest vs using the package manager. I've also just had this issue hit me on another machine where I fetched this same project, so in that case I suppose I have effectively manually edited the manifest from the pov of the second installation of Unity on a different machine where I didn't use the package manager.

Skimming the xr.management plugin then the XRPackageMetadata.cs code seems like a super likely suspect here, since it looks like it's trying to auto-magically update things - apparently _all_ the things, not even just XR related stuff. I kinda bet that if I instrument this code I'm going to find that this is what's updating the xr.management plugin.

In particular I see:
s_SearchRequest = Client.SearchAll(false);
which is explicitly asking the package manager for an "online" (i.e. not cached) list of all packages.

and then I see this function:
private static void UpdateInstallablePackages()
{
EditorApplication.update -= UpdateInstallablePackages;

if (s_SearchRequest == null)
{
return;
}

if (!s_SearchRequest.IsCompleted)
{
EditorApplication.update += UpdateInstallablePackages;
return;
}

s_InstallablePackages.Clear();

foreach (var package in s_SearchRequest.Result)
{
s_InstallablePackages.Add(package.name);
}

s_SearchRequest = null;

RebuildInstalledCache();
}

 

Right, although the error in 3.2.12 is the with Management code I'm suggesting that it's _also_ the equivalent (older) management code in 3.2.10 that is the recuring cause for the upgrade back to 3.2.12. The code quoted above is from 3.2.10 not the new 3.2.12 code.

Atm I think it would be a lot of work to strip down my project into something that's useful here partly because I don't have a reliable way of reproducing the issue so I wouldn't know what to keep/cut to be useful.

I think periodically my workflow will just the trigger the manager code I quoted above which then basically tries to upgrade everything. My gut instinct is that the XR manager code should never be trying to brute force upgrade all your packages. I would guess that also bypasses a user's packages-lock.json which also sounds bad.

In general I'd really like to remain in control of when packages for my project are updated.

 

Okey, my bad, I misinterpreted the code from skimming it.

The combination of seeing
s_SearchRequest = Client.SearchAll(false);
(query package manager for all packages)

and...
foreach (var package in s_SearchRequest.Result)
{
s_InstallablePackages.Add(package.name);
}

made me think it was updating all packages - though on closer inspection it looks like that code is only building a list of what's available to install - and as you say it also builds a cache of what's installed.

considering that something is apparently auto updating my plugin, and this xr.management code which is at the center of this issue at least looks from a glance like it tries to auto update stuff it just seemed likely.

Incidentally for the first time I've just had the pop up about checking for xr plugin updates (which has usually been the sign that the new 3.2.12 plugin is about to be installed) but it actually wasn't installed this time. Don't know if you've changed anything on your end but I think I just escaped the issue this time - I have my fingers crossed for next time

 

Unfortunatly i'm not. There are no other versions available in the package manager.
I can see older versions in most of the other packages, but not in this one.
How can i do that downgrade?