When documenting or introducing configuration mechanisms (env files, env vars, build/tox flags, config options), be explicit about what each mechanism is for, where it applies, and what is safe to commit to version control. Specifically:
.env file, make clear whether it’s meant to be committed or git-ignored, and warn that mixing secrets into a committed file is a common source of leaks..env files are only loaded by flask run/flask shell via the CLI, not in production WSGI servers like gunicorn — so don’t imply it solves production configuration too. Prefer scoped, environment-aware defaults (e.g., a committed wsgi.py entry point) over relying on uncommitted files for values needed in both dev and prod.tag_svn_revision only works with SVN — use tag_build/tag_date for generic dev builds; don’t widen a documented config type like PERMANENT_SESSION_LIFETIME to float just because it happens to work — document the intended, supported type).tox -e py) still work unmodified, and document any special syntax (such as negation markers) since such conventions are often poorly documented elsewhere.Example of a safer pattern instead of relying solely on .env for app location:
# wsgi.py (safe to commit)
from myapp import create_app
application = create_app()
This avoids encouraging users to store FLASK_APP/secrets together in an uncommitted file while still giving a simple, committed entry point for both dev and production.</description>
</invoke>