Repository navigation
Discussion: Error logging during packument resolving. #148
Description
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:
- The primary registry is searched, but the packument is not found
- 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:
- The primary registry is searched. The packument is found, but the requested version is missing.
- 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:
- The primary registry is searched. The packument and version is found but incompatible for the current editor version.
- 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 :)
Activity
favoyang commentedon Feb 11, 2024
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:
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 commentedon Feb 12, 2024
For Op1.
Example 1 & 2: The upstream registry is searched first and the packument is found.
Example 3:
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: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.
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 apackage@versionfailed, 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.Thought?
ComradeVanti commentedon Feb 12, 2024
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.