Loading env variable with empty prefix fails

[ykrasik]

Hi,

@dataclass
class Test:
    my_var: str

dataconf.env("").on(Test)

The above will fail in the environment contains a key of the format xxx_{int}=... i.e. a string, an underscore and a number that can be parsed as an int.
This line then considers p[1] to be an int, but focus does not contain the key p[0] at all and we get a Key error.

For example, my env contains 'EFC_5748': '1'. The above line is executed with these values:
p = ['efc', 5748]
focus = ret

focus does not contain the key efc

[zifeo]

@ykrasik Does it work when setting a prefix? The prefix was never tested to be empty and the _ will be automatically added in order to avoid already set environment variables per mistake.

[ykrasik]

It does, yes. I guess it is pretty much expected to have a prefix, with the unexpected keys validation coming afterwards.

[zifeo]

@ykrasik thanks for getting back, we should indeed manage that case explicitly 👍

[ykrasik]

That would be great. I'll find some workaround in the meantime - we don't use a prefix for env variable overrides, I might just parse it using pydantic settings and add as a dict.

[zifeo]

@ykrasik just to make it clear, I am not sure I will add support to handle the prefix-less case, but at least have an error message explaining why prefix are required for security. I could also add maybe an explicit flag if you can share more about why prefixes do not work on your end?

[ykrasik]

No particular reason, just currently we didn't have prefixes and I was trying to introduce this library in a backwards compatible manner to what we have now. I might add prefixes to the env vars if we don't have too many of them, or just work around it

[JCHacking]

In my case I use kubernetes, so I know that those environment variables are not read by any other application.

[zifeo]

@JCHacking To clarify, the prefix is designed to prevent conflicts, accidental collision and to ensure that variables are clearly scoped to the application.