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

Is there any way to read env vars from a .env file? #235

Closed
svanharmelen opened this issue Jan 11, 2023 · 6 comments · Fixed by #236
Closed

Is there any way to read env vars from a .env file? #235

svanharmelen opened this issue Jan 11, 2023 · 6 comments · Fixed by #236

Comments

@svanharmelen
Copy link

I've noticed #226 but I'm not able to get cargo watch to use my .env file. My setup involves a workspace, so next to placing the .env file in the root of the crate I'm trying to watch I also tried to place it in root of the workspace. But it didn't work in either of the cases...

Tried to search the docs/repo, but other then the one issue I can't seem to find much to go on. Would be really, really nice to be able to use my .env file, as I need quite a few vars to be set.

Thanks!

@passcod
Copy link
Member

passcod commented Jan 11, 2023

Not yet!

@passcod passcod mentioned this issue Jan 11, 2023
@svanharmelen
Copy link
Author

Wow, your fast 😃 My next question was going to be if you are open for a PR to support it and then I was going try and make some coming weekend... But I guess I don't have to anymore ❤️

One additional question after looking at the PR; would it be possible revert the logic using the same style as the --no-dot-ignores and --no-vcs-ignores flags? So on by default if an .env file is in the current working directory. And then maybe keep the --env-file flag for if you want to point to a custom file.

IMHO that would make the PR "feature complete" in terms of .env file support 😊

@passcod
Copy link
Member

passcod commented Jan 11, 2023

No, reading the .env by default would be unexpected, I think. Generally that's done by the application in development, not by the process parent. One advantage to doing it in the application is that it's reloaded on each run, whereas this option by necessity only loads it once at instantiation.

@svanharmelen
Copy link
Author

That's indeed a fair point! Then indeed the flag you proposed is a good alternative that would work fine for us 👍🏻

@passcod
Copy link
Member

passcod commented Jan 11, 2023

Released in 8.3.0

@svanharmelen
Copy link
Author

Thank you very much for the quick response and implementation!! Going to try it right away...

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

Successfully merging a pull request may close this issue.

2 participants