refactor: propagate version formatting errors

[vladimyr]

Description

Propagate errors originating from VersionFormatter#format_version to the upper level.

Motivation and Context

Continuation of #2499
(It got closed before I managed to leave my review.)

Screenshots (if appropriate):

How Has This Been Tested?

• I have tested using MacOS
• I have tested using Linux
• I have tested using Windows

Checklist:

• I have updated the documentation accordingly.
• I have updated the tests accordingly.

---

/cc @offbyone

[offbyone]

I'm mostly curious about the error handling rationale; I personally would prefer that version formatting be fairly silent, if possible, but that might be a "just me" philosophy. Otherwise, it looks like you reordered parameters in a few places, but ... ¯_(ツ)_/¯ different strokes for different folks :)

[offbyone]

What conditions would lead to this warning? I would rather just silently format the raw version than log a warning when this happens.

[vladimyr]

I would rather just silently format the raw version than log a warning when this happens.

This is silent unless you explicitly opt-in by setting STARSHIP_LOG environment variable to the warn level.

EDIT: warn is default log level so it gets print always but that is actually a good thing if you ask me

What conditions would lead to this warning?

The simplest case that would cause an error is a malformed version format like:

version = "v${raw" # missing right curly

This results in (with logging enabled):

[WARN] - (starship::modules::java): Error formating `java` version:
 --> 1:3
  |
1 | v${raw
  |   ^---
  |
  = expected variable_name

[vladimyr]

I'm mostly curious about the error handling rationale; I personally would prefer that version formatting be fairly silent, if possible, but that might be a "just me" philosophy.

As I explained above #2566 (comment) this is still silent. Error handling is moved to the upper level because version formatter doesn't know who called it thus can't print contextually rich warnings.

Otherwise, it looks like you reordered parameters in a few places, but ... ¯_(ツ)_/¯ different strokes for different folks :)

This speaks for itself ie I find the original version so good I didn't feel a need to change things around 😉
I did reordering to achieve the following form: format_version(version /*[1]*/, format /*[2]*/) where version is followed by format so it reads like: version formatter formats version [1] using provided format [2].

[vladimyr]

Otherwise, it looks like you reordered parameters in a few places

Actually, there is more than just that. I did 3 additional things there:

1. ensured that every format_{module}_version function has following signature format_{module}_version(version, version_string) (no context, config, just format string)
2. simplified version parsing in a few of those
3. renamed a bunch of java tests from test_parsing_* to test_format_* in order to follow already established convention