Skip to content

Cannot instantiate a class from env variables #680

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rusmux opened this issue Feb 20, 2025 · 2 comments
Open

Cannot instantiate a class from env variables #680

rusmux opened this issue Feb 20, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@rusmux
Copy link

rusmux commented Feb 20, 2025

🐛 Bug report

Cannot instantiate a class from env variables.

To reproduce

In main.py:

from jsonargparse import CLI


class Bar:

    def __init__(self, v: int) -> None:
        self._v = v


def main(b: Bar) -> None:
    print(b._v)


if __name__ == "__main__":
    CLI(main, default_env=True, env_prefix="FOO")

In shell:

export FOO_B__V=2
python -m main

Will result in the error:

usage: main.py [-h] [--config CONFIG] [--print_config[=flags]] [--b.help [CLASS_PATH_OR_NAME]] b
error: Validation failed: Key "b" is required but not included in config object or its value is None.

I can instantiate this class with:

export FOO_B="{v: 1}"
python -m main

But I cannot even override v:

export FOO_B__V=2
python -m main

Will still result in v being 1.

Expected behavior

I can instantiate a class from env variables. At least override fields.

Environment

  • jsonargparse version: 4.37.0
  • Python version: 3.12.8
  • How jsonargparse was installed: uv pip install -U "jsonargparse[all]"
  • OS: macOS
@rusmux rusmux added the bug Something isn't working label Feb 20, 2025
@mauvilsa
Copy link
Member

Thank you for reporting!

Note that not every possible name for environment variables is supported. And this wouldn't be considered a bug. In principle you should look at the output of --help to know what environment variable names you can use.

In this particular case b is a subclass type. So Bar or a subclass of Bar is accepted. And there is no guarantee that all subclasses have v. For command line arguments now the base class is implicitly chosen when an init arg that matches is given. This case looks similar but for env vars. But env vars are different because they don't have an order. Right now I am not sure if FOO_B__V should be supported in this case.

@mauvilsa mauvilsa added enhancement New feature or request and removed bug Something isn't working labels Feb 20, 2025
@mauvilsa
Copy link
Member

On a different note, since parameter b doesn't have a default, it becomes positional. But a subclass as positional is not really a use case. And I have noted that as positional, the output of --help doesn't show the env var FOO_B. Better to implement this as CLI(main, default_env=True, env_prefix="FOO", as_positional=False).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants