HOS-93: add support for .env file

[Kastier1]

All Submissions:

• Have you followed the guidelines stated in CONTRIBUTING.md file?
• Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

New Feature Submission:

• Does your submission pass the tests?
• Have you linted your code locally prior to submission?

Changes To Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully ran tests with your changes locally?

After these steps, you're ready to open a pull request.

a. Give a descriptive title to your PR.

b. Describe your changes.

c. Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such).

[linear]

HOS-93 Add .env file

[masenf]

so in this case, if the env_file is specified, then it overrides values defined in the environment already? is there any "automatic" env file? or is it only loaded if the user explicitly sets one?

---

remove stray print, merge from main, relock dependencies

[Kastier1]

There is no automatic env file. If they do no supply one we do nothing. If they do we use those values over what is in their env already.

[masenf]

looks good

[benedikt-bartscher]

Could we make the python-dotenv dependency optional?

[Kastier1]

Is there any reason in particular to make it optional?

python-dotenv is a small package with no other deps

We are looking into making this optional but was curious as to why you wanted this

[benedikt-bartscher]

Just trying to keep the list short in general. You're right, it's a rather small package, but it still needs to be maintained, updated, license reviewed etc. And it could (for some stupid reason) introduce other dependencies in the future.
In general, i prefer to make dependencies optional if they are not tightly coupled with the code.