Improbable Icon


Spatial CLI giving wrong hint + dependency resolution flows



Running on Windows 10 + powershell with choco.

When running spatial setup install-dependencies, it might sometimes try to install an older version of a package (like it happened to me with Unity). Therefore, the command returns with an error and suggests using either --force or --allow-downgrade.

–force doesn’t work for me. I had Unity installed without chocolatey, and it was a newer version than the one associated to SpatialOS version 10.4.1, so that might be it. It would be nice if that didn’t matter.
–allow-downgrade seems no longer available, I get “invalid flag” errors and I can’t see it listed when running spatial setup help. If it’s no longer available, it would be nice if the error message didn’t suggest it.

I had to manually choco uninstall unity and all of its dependencies one by one and then spatial setup install-dependencies worked fine, but it would be great if these issues were handled a bit more gracefully.



Hello @alejandro,

Sorry for the trouble. I understand your confusion. Here is what is going on:

The error message containing the --allow-downgrade or --force flags is a message from Chocolatey itself. Hence these flags are not associated with the spatial setup install-dependencies command (even if that command has its own --force flag, different from the suggested one).

What Unity version did you have installed? Normally spatial setup install-dependencies should not try to install anything unless you have an unsupported version installed. And even then it will just complain in general.

The most likely thing is that you had Unity installed in a non-standard location which we deliberately do not detect as such a non-standard installation would not work with the SpatialOS tooling (unless you have give a hint via the UNITY_HOME environment variable).

I understand and agree that it is not handled in the most graceful way, but if this was indeed caused by the non-standard location and / or unsupported version then there is little that we can do unfortunately.

Do please give all your possible feedback so we can make sure that we understand what has really been going on.

Best regards,


Hi Duco,

Thanks for the quick reply!

The Unity version I had installed was 5.6.2, which I downloaded directly from the Unity website and installed in a non-standard location indeed. I think I ran spatial setup install-dependencies with version 10.4.0, then spatial update, and then spatial diagnose with the PiratesTutorial, which is configured to use SpatialOS version 10.4.1 (associated to Unity 5.6.0) and returned the error saying Unity was not found. Subsequent calls to spatial setup install-dependencies from an admin shell succeeded, but the spatial diagnose error in the PiratesTutorial persisted.

I didn’t know about the UNITY_HOME environment variable, but I believe in Windows it’s a more standard practice to use the registry for these purposes (I’m not a Windows expert though). As an additional idea (maybe there’s something like that already) following GIT’s CLI approach, Spatial CLI could have something like spatial config --unity="C:\NonStandardPath\Unity", much in the same way GIT has git config to ser users, emails, etc. to avoid depending on the shell environment.