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

Add support for returning the file directory of loaded env file #362

Closed
senese opened this issue Nov 8, 2024 · 6 comments
Closed

Add support for returning the file directory of loaded env file #362

senese opened this issue Nov 8, 2024 · 6 comments

Comments

@senese
Copy link
Contributor

senese commented Nov 8, 2024

I miss the python-dotenv.find_dotenv() feature of returning the directory which the env file is placed.

Is there anything similar in environs? Are you accepting PR?

Thanks!

@sloria
Copy link
Owner

sloria commented Nov 8, 2024

This functionality doesn't exist within environs. I'd be open to a PR that just delegates to python-dotenv. We should also probably refactor read_env to delegate to find_dotenv as well. I made an issue for that #363

@senese
Copy link
Contributor Author

senese commented Nov 8, 2024

I believe is not necessary to delegate to python-dotenv as it's already loading the environment with the path that read_env is searching.

IMHO there is no right or wrong on how to implement this, just pros and cons. I notice that creating an instance of Env() is the main way to use environs (even the docs exemplifies that), so I quite not understand why read_env is a static method. I tried to remove @staticmethod decorator and all the tests have passed. Changing to an instance method would allow read_env to store the env path in a instance variable so that it is always available for the user (instead of returning when calling the function).

So I strongly advice to change read_env to a instance method in a major release (along the refactoring) as it breaks compatibility with other codes that are using the staticmethod version.

For the PR I try to maintain the code style and not to break compatibility, just adding an optional parameter for the user to receive a boolean or string return type.

@sloria
Copy link
Owner

sloria commented Nov 9, 2024

Thanks for looking into this @senese . I like your proposal to change read_env to an instance method and store the path as an attribute.

I think we can should just go ahead and make that change now, even though it is breaking. I plan to update Python version support anyway, so it's about time for a major release.

Can you please update your PR accordingly?

senese added a commit to senese/environs that referenced this issue Nov 10, 2024
@senese
Copy link
Contributor Author

senese commented Nov 10, 2024

Hi @sloria! Glad you like my idea.

I would suggest that we could add this feature with a minor release and work on the instance method in a next PR. I've seen on pypistats that environs had millions of downloads last month (kudos!!) and it will be nice to add a feature to the library before a breaking change. We don't know the environment and restrictions of the users and other libraries using environs.

For this issue I fix the return type as the Union operator | wasn`t a thing for Python 3.8 and 3.9 versions.

@sloria
Copy link
Owner

sloria commented Nov 10, 2024

Works for me. Thanks!

sloria added a commit that referenced this issue Nov 11, 2024
…nts #362 (#364)

* feat: Add support for returning the file directory of loaded env file - Implements #362

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* fix return type for python 3.8 and 3.9 (#362)

* Update changelog

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Steven Loria <[email protected]>
@sloria
Copy link
Owner

sloria commented Nov 11, 2024

closed by #364

@sloria sloria closed this as completed Nov 11, 2024
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

2 participants