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

Pydantic BaseSettings should raise when .env file specified in env_file does not exist #4

Open
3 of 13 tasks
ralbertazzi opened this issue Sep 28, 2022 · 4 comments
Open
3 of 13 tasks

Comments

@ralbertazzi
Copy link

Initial Checks

  • I have searched Google & GitHub for similar requests and couldn't find anything
  • I have read and followed the docs and still think this feature is missing

Description

Thank you for adding settings management to Pydantic, it's a pleasure to use a single well-done library to manage both models and settings from .env files and environment variables! 😍

I'm not sure about its future in Pydantic V2 (👀 please don't remove it 🙏 ) since I can't find references in the main branch anymore. Still I'd like to mention a small improvement that could be done when reading .env files.

Currently, if the .env file does not exist it is simply ignored. I don't know if this is done by design but I would actually prefer a strict behaviour that raises an error asap.

What happened to me instead is that I provided a wrong path in the env_file and pydantic later raised with a ValidationError for missing fields that were specified in the .env file. I still consider this a lucky case because an error was eventually raised. What would have been worse is if my settings had defaults for every field, which would have resulted in no ValidationError being raised at all!

Let me know what do you think about it. If you have a strong preference for the current behaviour I guess I could always add some file existence check before parsing my settings. Still, it would be nice to have this done by Pydantic IMO.
Could you also share an update on the planned support for settings in V2? In the online v2 plan there isn't a final answer, but I imagine you have already taken actions on it.

Thank you so much and keep making Pydantic one of the best libraries of the Python ecosystem 🚀

Affected Components

@ralbertazzi ralbertazzi changed the title Pydantic should raise when env_file is Pydantic settings should raise when .env file specified in env_file does not exist Sep 28, 2022
@ralbertazzi ralbertazzi changed the title Pydantic settings should raise when .env file specified in env_file does not exist Pydantic BaseSettings should raise when .env file specified in env_file does not exist Sep 28, 2022
@samuelcolvin samuelcolvin transferred this issue from pydantic/pydantic Sep 28, 2022
@samuelcolvin
Copy link
Member

(transferred the issue to pydantic-settings)

Settings management will remain, but it'll be managed as a separate repo and pypi package.


On that issue, the idea is that you might have and .env.development (which is not available in production or on CI) and and .env.production which is only available in production.

So pydantic-settings shouldn't (by default) raise an error if an env file is missing.

Ideas to work around this:

  • add comprehensive logging to pydantic-settings so you can see ".env.production loaded....env.development not found" etc.
  • add a way to mark a particular env file as required

WDYT?

@samuelcolvin
Copy link
Member

We're also changing how settings works to use "sources" for all sources in V2, so it should be easy to customise the EnvFileSource to make files required.

@samuelcolvin
Copy link
Member

Thank you so much and keep making Pydantic one of the best libraries of the Python ecosystem rocket

Thanks so much, comments like this mean a lot.

@ralbertazzi
Copy link
Author

We're also changing how settings works to use "sources" for all sources in V2, so it should be easy to customise the EnvFileSource to make files required.

I think having an easy boolean in EnvFileSource to customize the behaviour is the best thing! At that point I'm fine with any default behaviour :)

I didn't think about the use case you mentioned. In my setup the .env files of every environment are committed in the repo and always available, while we manage secrets and extra configuration known at runtime with environment variables.

Thanks so much, comments like this mean a lot.

I truly mean it! I started being a lover of this library since the dark days of marshmallow 😛

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

No branches or pull requests

3 participants