Migrate to __future__.annotations

[oerc0122]

Following discussion quick migration to future annotations and | union syntax globally.

N.B. Does not update doc labels.

[ElliottKasoar]

I've been looking at this too, and somewhere the changes in janus_core/cli cause errors.

Also, if you haven't run ruff format after the fixes, the spacing will be wrong

[oerc0122]

I've been looking at this too, and somewhere the changes in janus_core/cli cause errors.

Also, if you haven't run ruff format after the fixes, the spacing will be wrong

Is that due to the fact that the Annotated is processed in typer?

[ElliottKasoar]

There have been issues relating to that, which may not be completely solved (fastapi/typer#802), but this seems to be from TyperDict specifically, not Annotated, as I can "fix" cli/utils.py, cli/types.py, and cli/train.py without problems, but not cli/singlepoint.py, for example.

[oerc0122]

There have been issues relating to that, which may not be completely solved (fastapi/typer#802), but this seems to be from TyperDict specifically, not Annotated, as I can "fix" cli/utils.py, cli/types.py, and cli/train.py without problems, but not cli/singlepoint.py, for example.

We can add exceptions to the CLI files noting the issue, I guess.

[oerc0122]

We have a bit of a choice. Do we want file-level disabling of I002, FA100 (not importing future annotations)

#ruff: #noqa: I002, FA100

at the top of each CLI file or do we want a pyproject.toml level disable?

[tool.ruff.lint.per-file-ignores]
# Ignore __future__ annotations import in CLI folder.
"janus-core/cli/**.py" = ["I002", "FA100"]

[ElliottKasoar]

So actually I think typer itself may not actually to blame.

It seems to be specifically caused by @use_config (from typer-config, rather than typer), in combination with the custom types and annotations, because it uses inspect.signature:

    def decorator(cmd: TyperCommand) -> TyperCommand:
        # NOTE: modifying a function's __signature__ is dangerous
        # in the sense that it only affects inspect.signature().
        # It does not affect the actual function implementation.
        # So, a caller can be confused how to pass parameters to
        # the function with modified signature.
        sig = signature(cmd)

        config_param = Parameter(
            param_name,
            kind=Parameter.KEYWORD_ONLY,
            annotation=str,
            default=Option("", callback=callback, is_eager=True, help=param_help),
        )

        new_sig = sig.replace(parameters=[*sig.parameters.values(), config_param])

        @wraps(cmd)
        def wrapped(*args, **kwargs):  # noqa: ANN202,ANN002,ANN003
            # NOTE: need to delete the config parameter
            # to match the wrapped command's signature.
            if param_name in kwargs:
                del kwargs[param_name]

            return cmd(*args, **kwargs)

        wrapped.__signature__ = new_sig  # type: ignore

        return wrapped

    return decorator

which I think means the custom info isn't copied properly.

signature seems to generally have problems, with solutions e.g. eval_str only introduced for 3.10+.

[ElliottKasoar]

We have a bit of a choice. Do we want file-level disabling of I002, FA100 (not importing future annotations)

#ruff: #noqa: I002, FA100

at the top of each CLI file or do we want a pyproject.toml level disable?

[tool.ruff.lint.per-file-ignores]
# Ignore __future__ annotations import in CLI folder.
"janus-core/cli/**.py" = ["I002", "FA100"]

I don't mind too much, but being explicit per file is maybe a bit clearer, so I'm happy with the current form.

Only thing left is I think the explanations should be updated.

I should probably open an issue in typer-config, which we can reference? (I was going to do a PR too to set eval_str, before discovering that the solution doesn't work for Python 3.9)