Discussion: Error logging during packument resolving.

[ComradeVanti]

While working on more complex packument resolving logic, I came upon an open question, that I would like to open to discussion. That is concerning, which errors/infos should be printed to the user while resolving packuments.

Here are a few examples that I would like to get others opinions on. I provide the scenarios for the primary and upstream registry, but please imagine it for n registries, in the case that #49 is implemented.

Example 1

Scenario:

1. The primary registry is searched, but the packument is not found
2. The upstream registry is searched and the packument is found

Question:

Should the "Packument not found" error for the primary registry be logged? In my opinion, no, because it is overruled by the packument being found in the upstream registry.

Example 2

Scenario:

1. The primary registry is searched. The packument is found, but the requested version is missing.
2. The upstream registry is searched. The packument is found.

Question:

Should the user be informed that the packument was found in the primary registry?

Example 3

Scenario:

1. The primary registry is searched. The packument and version is found but incompatible for the current editor version.
2. The upstream registry is searched. The packument is not found.

Question:

Should the user be informed that the packument was found in the primary registry, or should it count as a "packument not found", since it was not found in the "last" registry.

---

The above examples can be generalized to: If I search n registries and the different registries match the query differently well (some don't contain the packument, some have it, but not the version, some are incompatible, etc.) how should this information be presented to the user? Should all issues be logged? Only the "most fixable"? Only the last?

I'm curious to hear your opinions :)

[favoyang]

See #41 (comment).

Op1, If we take the priority of [upstreamRegistries..., primaryRegistry] from higher to lower (which is the opposite of the current behavior), then the logging is easier to define:

• Search registries in order of [upstreamRegistries..., primaryRegistry].
• Stop for the first matched packument by name.
• Log an error if the found packument doesn't satisfy the desired version.
• Log an error if no packument is found after searching all candidates.

This removes the ability to overwrite an upstream registry package by creating the same named package in the primary registry, which can be chaotic, and probably a false promise depending on Unity Packman's behavior. It's better to give the upstream registries a higher priority.

Op2, Just for discussion, if we take the primary registry higher priority, then we have to search for reverse([upstreamRegistries..., primaryRegistry]), and continue the search even until find the desired package name and version, or log an error after the all candidates get searched.

I prefer the Op1.

[favoyang]

For Op1.

Example 1 & 2: The upstream registry is searched first and the packument is found.

Example 3:

1. The upstream registry is searched first. The packument is not found.
2. The primary registry is searched. The packument and version is found but incompatible for the current editor version.
3. Informed the user that the packument not found.

Extra logging for debugging/inspecting

Log all action/extra info in the debug level. In case a user gets curious about what happens internally, just use --verbose:

• Search registry X and get 404.
• Search registry X and get matched packument.
• packument found but failed to match the desired version.
• packument found but failed to match the Unity editor version.

Handle network error/server 5xx error

If one of the registry chains failed with a network error a server failure 5xx. Stop the whole search and inform the user of the issue.

Inform "fixable" error message

The Unity editor just shows an error message for package version mismatch.

Package has invalid dependencies: ... [packagename@version] cannot be found.

If we want to show a "fixable" error message by default (without --verbose) for Unity editor version mismatch and package version mismatch (like the CLI already offered). Then when resolving a package@version failed, we can go through (a temp) error message list, then find all Unity editor version mismatch and package version mismatch, and log all of them in the warn level.

Cannot find pkg@version
- found the pkg at registry X, but can not find the desired version `version`.
- found the pkg@version at registry X, but the required Unity editor version `x.y.z` does not match with the current Unity Editor version `x1.y1.z1`.

Thought?

[ComradeVanti]

Seems good to me. I will keep the issue open, in case anyone else wants to chime in, otherwise I will do as you suggested.