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

Adding comments to end of lines #2

Open
jwoertink opened this issue Mar 3, 2021 · 3 comments
Open

Adding comments to end of lines #2

jwoertink opened this issue Mar 3, 2021 · 3 comments
Labels
question Further information is requested

Comments

@jwoertink
Copy link
Member

The env parser bundled with Lucky fails on this:

SOME_ENV=useless # this isn't used

Should this be something we should allow? 🤔

@jwoertink jwoertink added the question Further information is requested label Mar 3, 2021
@hovsater
Copy link
Contributor

hovsater commented Jul 2, 2021

While the parser should not fail on the given input, I don't think it should treat it as a comment. As an example, Docker only support comments in .env files if the line starts with a #. If it does not, it's treated as a value.

This can be proven by creating a .env file with the above contents and then run the following

$ docker run --rm -it --env-file .env alpine:3.14 sh -c 'echo $SOME_ENV'
useless # this isn't used

@jwoertink
Copy link
Member Author

Yeah, right now LuckyEnv does the same as Docker: ENV["SOME_ENV"] == "useless # this isn't used". It was the dotenv shard that fails. It might be fixed by this point, but at the time that would throw an error.

So with that said, let me toss this at you and get your thoughts @kevinsjoberg. My plan is eventually that our .env files would look completely different and would not 1-1 with other dotenv parsers. See #1 for more on that. So, should this shard return "useless" and ignore the rest provided that you didn't do something like SOME_ENV="value # with comment"? Because in that instance it's obvious that you're wanting the string literal...

@hovsater
Copy link
Contributor

hovsater commented Jul 3, 2021

My plan is eventually that our .env files would look completely different and would not 1-1 with other dotenv parsers. See #1 for more on that.

I like the direction you're taking in #1. 🙂 On a parser level, I think it makes sense to keep compatibility with other Dotenv parsers for the sake of ergonomics. Depending on how deployment is setup, the "Lucky env" file would be a candidate for being used by tools such as Docker or Kubernetes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants