CLI package resolution throws exceptions for packages that work fine in Unity

[hybridherbst]

Bug report

Running openupm add org.khronos.unitygltf results in exceptions in the CLI.
Running with -f works fine and results in a working project.

See

• ShaderGraph dependency problem for OpenUPM install KhronosGroup/UnityGLTF#704

Bug category

• CLI

Steps to reproduce

• Make a project on Unity 2022.3
• Run openupm add org.khronos.unitygltf
• Note exceptions in the CLI about package resolution
• Run openupm add org.khronos.unitygltf -f and note it actually works fine

We've been using 10.0.0 as dependency forever, and Unity will always auto-upgrade older ShaderGraph versions to the correct built-in version actually available in each specific version of Unity.

What is expected?

No error in the openupm CLI, makes it look as if dependencies would be wrong in the package.

What is actually happening?

Exception in the CLI

[favoyang]

Regarding the reference #133, Unity has ceased using the registry for built-in packages. Now, built-in packages are resolved from the "BuiltInPackages" folder included with the Editor. If there is a version mismatch, it simply gets ignored.

For now, use -f until #133 gets fixed.

A test for Unity2022.3.17f1:

[ComradeVanti]

Does this issue have any difference to #133? If not we could close it right?

[favoyang]

Does this issue have any difference to #133? If not we could close it right?

Yes and no.

org.khronos.unitygltf depends on com.unity.shadergraph@10.0.0. Because Unity always uses the built-in version shipped with the editor, it will work fine.

#133 wants to resolve this issue. However, 10.0.0 is not an existing version. The only 10.0.x version (paired with Unity 2020) is 10.0.0-preview.27 and is available on the Unity registry.

Depends on how #133 is implemented

• If we verify the Unity built-in package version strictly (search from the Unity registry, then the version list from manual docs, perhaps reading local editor built-in package folder), the author are required to set a valid version (10.1.0 for example).
• Otherwise, this issue is fixed if we ignore version verification for Unity built-in packages.

[favoyang]

Depends on how #133 is implemented

• If we verify the Unity built-in package version strictly (search from the Unity registry, then the version list from manual docs, perhaps reading local editor built-in package folder), the author are required to set a valid version (10.1.0 for example).
• Otherwise, this issue is fixed if we ignore version verification for Unity built-in packages.

After reading the implementation of #364, the built-in package version verification has been bypassed. Then this will be resolved with it.