we try to bring all MRTK related packages to a scoped registry for easier version tracking and CI/CD purposes (including the MagicLeap packages). We saw that a lot MRTK packages and also the MRTK3 MagicLeap package have their dependencies set to release packages, e.g. 3.0.0. But the dependent packages versions of all MRTK3 packages are 3.0.0-development.
The Unity Package Manager interprets 3.0.0-development to be a lower version than 3.0.0. Therefore, packages on a scoped registry can't find dependency packages with a version of 3.0.0.
I created already a discussion on the MRTK GitHub repository for the same reason:
The MRTK3 Template Project only uses local dependencies which is why it's not a problem, I assume? Would it make sense to change the dependencies of the Magic Leap MRTK3 package to 3.0.0-development versions to be more precise and support scoped registry dependency resolvings?
Thank you for reporting this. We support either the "-development" packages as well as the officially released, clean looking, versions like "3.0.0" without the -development.
The issue is more with Unity and how the Package Manager doesn't see "3.0.0-development" as satisfying the "3.0.0" dependency when you are obtaining packages via NPM scoped registry. It works fine if your package is local or in a tarball I think, but not when you're querying the NPM scoped registry. However I have brought this up to our MRTK team .
The issue is more with Unity and how the Package Manager doesn't see "3.0.0-development" as satisfying the "3.0.0" dependency when you are obtaining packages via NPM scoped registry. It works fine if your package is local or in a tarball I think, but not when you're querying the NPM scoped registry.
Yes, that's what we experienced as well.
I was informed on the MRTK forum that there are already published packages (without the -development) on the GitHub page. The fix would be to publish those version instead of the packages from the source tree.
