Lightning CLI should use fail_untyped=True

[cristianregep]

Outline & Motivation

Use fail_untyped=True here https://github.com/Lightning-AI/lightning/blob/97020bf8d7a88ca5195534b8585a5ef53f1ce6cb/src/lightning/pytorch/cli.py#L135 and here https://github.com/Lightning-AI/lightning/blob/97020bf8d7a88ca5195534b8585a5ef53f1ce6cb/src/lightning/pytorch/cli.py#L139

Pitch

I have spent quite a bit of time with the same issue described here #15741 . The person there also reported spending "several days". I finally figured it out when I created an isolated example with just jsonargparse which told me "Types as a string and from __future__ import annotations is currently not supported" . That was because CLI has fail_untyped=True by default . I do believe it would be better to have that as default to ease debugging. If not by default, maybe allow users to set that themselves.

I do know that from version 4.22 of jsonargparse this specific example is no longer an issue omni-us/jsonargparse#120 , but my point is more about the general principle of having fail_untyped=True

Additional context

No response

cc @justusschock @awaelchli @Borda @carmocca @mauvilsa

[carmocca]

This cannot change because it would be a breaking change for CLI users who don't want to type their code. Many Python users are also against typing their scripts so it would make the LightningCLI opinionated.

However, maybe that specific error should be shown regardless of the value of fail_untyped

[cristianregep]

Thanks @carmocca for the quick reply. That make sense, a lot of people may be using the cli without typed code . What if the constructor of LightningArgumentParser allowed you to set fail_untyped (and by default it would be false as to not introduce a breaking change).

[carmocca]

We'd accept this contribution if you want to open a PR. The LightningCLI already exposes parser_kwargs

[cristianregep]

Thanks. I will submit a PR this week.