--env-file flag like in docker or node.js

[AlbertSabirzianov]

Feature or enhancement

Proposal:

Feature Request: Add --env-file flag to the Python CLI

Summary

Proposal: Add a new command-line flag --env-file to the Python interpreter.
Purpose: To allow developers to load environment variables from a file (e.g., .env) directly at runtime, simplifying local development and configuration management.

Motivation

In modern software development, environment variables are the standard way to manage configuration. In production environments (e.g., Docker containers, cloud platforms), these variables are typically injected by the host system.

However, during local development, developers often need to manually load these variables from a file. Currently, this requires the use of third-party libraries such as python-dotenv or load-dotenv, which adds an extra dependency and a boilerplate line of code to every project.

This proposal aims to bridge that gap by introducing a native, zero-dependency solution directly in the Python CLI, making the development workflow more consistent and convenient.

Proposed Implementation

The new flag would be used as follows:

python main.py --env-file .env

Behavior:

1. Loading Mechanism: When the --env-file flag is present, the Python interpreter should read the specified file before executing the script.
2. File Format: The file should follow the standard KEY=VALUE format (one variable per line).
3. Environment Injection: All variables defined in the file should be loaded into the process's environment (os.environ).
4. Precedence: Variables loaded from the file should not overwrite existing environment variables set in the host shell, unless explicitly designed to do so.
5. Error Handling: If the specified file does not exist or is unreadable, the interpreter should display a clear error message and exit with a non-zero status code.
6. Precedent: This behavior is already widely adopted and familiar to developers from other ecosystems, such as Docker (--env-file) and Node.js (dotenv).

Example

File: .env

DATABASE_URL=postgresql://user:password@localhost/dbname
DEBUG=True
SECRET_KEY=your_secret_key_here

File: main.py

import os

def main():
    print(f"Debug mode: {os.getenv('DEBUG')}")
    print(f"Database URL: {os.getenv('DATABASE_URL')}")

if __name__ == "__main__":
    main()

Execution:

python main.py --env-file .env

Output:

Debug mode: True
Database URL: postgresql://user:password@localhost/dbname

Benefits

• Simplified Development Workflow: Eliminates the need for boilerplate code and external libraries for loading configuration during development.
• Consistency: Aligns Python's command-line interface with established patterns in other popular tools (Docker, Node.js), making it more intuitive for developers.
• Zero Dependencies: Allows small scripts and projects to use environment-based configuration without adding extra packages to their requirements.
• Improved Onboarding: New developers can start a project by simply running a single command with a provided .env file.

Conclusion

Adding a --env-file flag to the Python interpreter is a small but impactful quality-of-life improvement that would significantly enhance the developer experience for a vast number of Python projects. It promotes best practices in configuration management while reducing friction in local development environments.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[picnixz]

Sorry but this is a feature that is non-trivial and IMO, not the responsibility of the interpreter. It should be the responsibility of the container running the interpreter (or an IDE, or anything else).

If you want to suggest this, you should first open a discussion on https://discuss.python.org/c/ideas/6. You could suggest adding this to virtualenv only though but I'm not convinced about it without a community consensus.

[picnixz]

I also missed but:

Currently, this requires the use of third-party libraries such as python-dotenv or load-dotenv, which adds an extra dependency and a boilerplate line of code to every project.

In this case, I believe it's better to leave it there.