Skip to content
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

Some environment variable are not parsed #167

Open
vrtexe opened this issue Jul 25, 2024 · 2 comments · May be fixed by #169
Open

Some environment variable are not parsed #167

vrtexe opened this issue Jul 25, 2024 · 2 comments · May be fixed by #169
Assignees
Labels

Comments

@vrtexe
Copy link

vrtexe commented Jul 25, 2024

Running the following command:

docker run --rm -it --name simple-webdav -v /data -p 6060:6060 \
-e WD_PORT=6060      \
-e WD_PREFIX='/dav'   \
-e WD_SCOPE='/data'  \
-e WD_AUTH='false'    \
-e WD_MODIFY='true'  \ 
-e WD_DEBUG='true'   \
 hacdias/webdav ''

The WD_AUTH and WD_PREFIX seem to be parsed correctly and the problem i experienced was that the WD_MODIFY and WD_SCOPE were not working, after doing some analysis, the problem might occur because the Permission is nested within Config, while this works for parsing in the default way with flags and config file, it does not work with environment variables.

Possible solution i tried that might work would be to use something like v.BindEnv("field"), looking at the tests of the library used for loading configurations, specifically this one: https://github.com/spf13/viper/blob/cc53fac037475edaec5cd2cae73e6c3cc5caef9e/viper_test.go#L967, seems to fix this nesting issue however that feature is still not shipped.

And as it states in their documentation here, that with AutomaticEnv only loads the value when a v.Get("FIELD") is called, and they probably do not call it for the nested structures, when they get the keys it only reads the 'outside' values during unmarshaling.

@hacdias
Copy link
Owner

hacdias commented Jul 25, 2024

Very interesting. Thanks for reporting. I also just did some testing, and setting default values for these options seem to fix the problem. That's a bit odd, but it works (see #168). I will probably merge the workaround for the top-level keys, but it would be great to have a better idea on why this is happening.

@hacdias hacdias linked a pull request Jul 25, 2024 that will close this issue
@hacdias hacdias added the bug label Jul 25, 2024
@hacdias
Copy link
Owner

hacdias commented Jul 25, 2024

I just merged #168 as a temporary fix. #169 will come in due time.

@hacdias hacdias self-assigned this Jul 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants