@Bikappa, could you please rebase the PR from the master? On IDE2's side, I need this change but also need #2102 to have zero compiler errors. Thank you!

Update

Never mind, I did it on https://github.com/kittaakos/arduino-cli/tree/feat/more-error-details

@kittaakos the error code has been updated to be the one you expect.

In regards to the kind of origin (builtin or 3rd) party, I tried looking into the code, but it turns out to be easier said than done. The current logic has to be stretched out quite a bit in order to collect the info about the origin and bring it to the output. I also don't know if we really want to maintain that.

I propose to merge this as-is now and start thinking about a common error source design that provides structured metadata for non-human clients. For example:

{
type: "Error",
message: "An error occurred while installing library \"foo\".",
...,
cause: {
 entities: [{
 type: "Library",
 vendor: "Arduino"
 name: "Foo",
 version: "x.y.z",
 managed: true // --> comes out-of-the-box or not
 }],
 action: "install",
 offence: "missing" | "conflict" | ...,
 remediations: [{
 ... 
 }]
}

It would then be up to the client to define their own heuristic on the software status and wether or not it is operable for their purposes.

the error code has been updated to be the one you expect.

Thank you, @Bikappa

I also don't know if we really want to maintain that.

IDE2 needs to decide somehow.

propose to merge this as-is now

Sure, I will discard my review, and you can proceed with the merge. On the other hand, IDE2 would be the only client of this API but cannot use it, so merging this PR does not change anything.

common error source design that provides structured metadata for non-human clients. For example:

IDE2 has been waiting for this since day one. I am sure there could be a more sophisticated way of propagating application-specific errors between IDE2 and CLI, but surely adding another enum type FAILED_INSTANCE_INIT_REASON_INDEX_LOAD_ERROR -> FAILED_INSTANCE_INIT_REASON_PRIMARY_INDEX_LOAD_ERROR seems a lot easier to indicate what has gone wrong.

FAILED_INSTANCE_INIT_REASON_INDEX_LOAD_ERROR -> FAILED_INSTANCE_INIT_REASON_PRIMARY_INDEX_LOAD_ERROR seems a lot easier to indicate what has gone wrong.

Surely it looks an easy design, but, maybe not for this specific one, several errors come to the initialisation logic similarly to how clients see them: as a black-box "error" thing that has a message. And these are just forwarded.
I'd like to not proceed in an patch-and-fix strategy, but have a coherent error bubble up strategy for all of them, at least in principle, cause we all know it won't be perfect :)

From the errors point_up_2, IDE2 does not know if primary package index loading has failed or if it's a 3rd party platform.

I think this will be solved when we fix #1529: it basically requires that the first Init call will trigger an index-update if the main index is missing, this would offload the IDE from the duty of understanding the reason of the failure and triggering an update on his own.

#1529 should have made the Init process much simpler and removed the need for most of the error code exposed here.