Refactor Use pydantic-settings for env vars

[K-dash]

@ryansurf
Sorry for bombarding you with pull requests one after another!

I refactored the environment variable loading process (os.getenv()) and used pydantic-settings to make it type-safe!

Maybe you know, The benefits of pydantic-settings are:

• You can define the expected type for each environment variable using pydantic-settings. When the Python script runs, it automatically validates the loaded values against the specified types. This helps catch errors in the environment variable values early on, preventing the process from proceeding with incorrect settings.

  • If the type is wrong, it'll throw an error at runtime.

• With pydantic-settings, you can define all the environment variables in a centralized configuration class(settings.py). This makes it easier to manage and maintain the configuration settings in one place, improving code organization and readability.

Thanks to this, send_email.py now throws an error if the email address isn't set, for example.

This changed commit: c2f5bf5

I'd be stoked if you could merge this in!!

---

Also, I know this article is in Japanese, but I wanted to share a piece I wrote about pydantic-settings:)
https://qiita.com/inetcpl/items/b4146b9e8e1adad239d8

[ryansurf]

This is awesome. I didn't know about pydantic-settings but it looks great.

For send_email.py, will an error be thrown but everything runs as expected? I think that's what will happen, the email settings are optional

Nice job on this PR! Article was interesting too :D

Merging

[ryansurf]

Just to make sure, we can get rid of the .env file, right? Redoing the docs

[K-dash]

@ryansurf
Thanks for merging this PR!
You're right, the email settings are optional, and when send_email.py runs, it will check if the values in .env conform to the expected types.
As long as send_email.py isn't executed, other processes like server.py and cli.py won't be affected.
I'm planning to add some test code later to verify that the settings in settings.py are correct.

Also, thanks for checking out my article! :D

[K-dash]

Just to make sure, we can get rid of the .env file, right? Redoing the docs

Thanks for the follow-up question.
If I understand correctly, you're asking about the behavior when running the code without the .env file (i.e., when the .env file doesn't exist), right?

[ryansurf]

Exactly, from my understanding the settings.py file replaces the .env file. Is that correct?

[K-dash]

Exactly, from my understanding the settings.py file replaces the .env file. Is that correct?

No, that's not quite right!
The settings.py file is responsible for loading and validating the types of values from the .env file.
This means that the .env file is still necessary, and users will need to continue writing configuration values in the .env file, just like before.

[K-dash]

# settings.py
class CommonSettings(BaseSettings):
    """
    Base class for defining common settings.
    model_config (SettingsConfigDict)Configuration dictionary
    for specifying the settings file and encoding.
    """

    model_config = SettingsConfigDict(
        env_file=f"{Path(__file__).parent.parent}/.env",
        env_file_encoding="utf-8",
        extra="ignore",
    )

The .env file is being loaded by the settings.py file through the line env_file=f"{Path(__file__).parent.parent}/.env".

[K-dash]

Apologies for the lack of clarity in my explanation!

To summarize:

• The .env file is necessary, and users will input their configuration information into the .env file.
• The settings.py file reads the .env file and validates whether the values conform to the specified types. If there are any issues, it will output an error.
• If there are no problems with the input values, the application can import settings.py to access the loaded environment variable values that have been "type-validated".

Sorry for the confusion😵‍💫

[K-dash]

Please point out if I'm missing the point of your response, as I may not have understood the exact intent of your question.🙂‍↕️

[ryansurf]

Ah, that makes sense. Sorry, I was being a bit lame, you answered what I was asking 👍