[Django] django-environ を使用する際に、OSに設定されている環境変数名と全く同じ変数名の環境変数を.envに記載した場合にも、.envの値を読み取りたい

Question

そもそもできないんじゃないか、、、、とも思っていますが、誰かご存じかもしれないので念のため確認します。

# やりたいこと

タイトルの通りです。

たとえば、OSに`USER`という環境変数が設定されており、`hoge`だとします。
そして、`.env`ファイルにも`USER`という環境変数を設定し、そこには`user`という値を設定したとします。

このときに、`user`という値を読み取りたいです。
しかし、実際には`hoge`という値しか読み取ることができませんでした。

ちなみにですが、**OSに設定されていない環境変数であれば`.env`に設定した値を正しく読み取れる**ことは確認できています。

あくまでも、OSと.envで重複する環境変数を設定している場合のみの問題になります。

# 試したこと

OSと.envどちらを優先させるかを指定するようなオプションがないか調べるため、公式ドキュメントで`read_env()`メソッドを調べてみましたが、それらしいオプションは見つかりませんでした。

[https://django-environ.readthedocs.io/en/latest/index.html?highlight=read_env#environ.environ.Env.read_env](https://django-environ.readthedocs.io/en/latest/index.html?highlight=read_env#environ.environ.Env.read_env)

# 代替策を渋る理由

まぁ、
- 環境変数名変えたら？
- OSの環境変数消したら？

という話なのは薄々感じています。

感じてはいるんですが、複数のアプリケーション、複数種類のDBが動くOSにおいて、複数のアプリケーションの.env内で同じ環境変数名を使えたらいいな...というのが希望です。

（既に構築されていたアプリケーションがOSの環境変数を使っている模様...しかも、それがどのアプリケーションの環境変数なのかわからない.....

# 追記（2021/07/24）

こちらの記事に、`python-dotenv`であれば、OSの環境変数を上書きできるとの情報が載っていました。

https://maku77.github.io/python/env/dotenv.html

以下のようにして実施できるようです。

> ```
> from dotenv import load_dotenv
> load_dotenv(override=True)
> ```

これと同じことを、`django-environ`で行いたいだけなので、おそらく何かしら方法はあるはず（ちょっと時間がないのでここまでの記載にとどめておきますが、後で調べる予定です）

Accepted Answer

## 回答としての結論

多分ですが、`django-environ`を素直に利用する範囲においては、「`USER`を`.env`で上書きする」ことは難しい気がします。

## 理由：read_envの仕組み

read_envの内部でやっていることは、大まかに書くと次のとおりです。

- 指定された引数に基づいて、env_fileの読み込みを行い
- `os.environ`で未使用なキーに対して、初期値を与える
- 更に`overrides`の内容が存在した場合に、未使用なキーに対して初期値を与える

※[django-environのソース](https://github.com/joke2k/django-environ/blob/master/environ/environ.py#L614)より
※内部的には`cls.ENVIRON`に対する処理ですが、`Env`クラスでは`os.environ`が指定されているので同じとみなします

重要なのは`os.environ[key] = value`ではなく[`os.environ.setdefault(key, value)`](https://docs.python.org/ja/3/library/stdtypes.html#dict.setdefault)としているところです。
この実装のため、Djangoアプリケーション実行までに用意されている環境変数は原則として上書き利用することは出来ません。

## 無理やりする例

一見スマートに見えそうな解決方法を試しに考えてはみました。
...があまり意味がないか、`django-environ`が本質的にやりたいことを捻じ曲げてそうな気はします

## `django-environ`のread_envを書き換えたクラスを用意する

```python
import os
from environ import Env

class MyEnv(Env):
    ENVIRON = {}

    @classmethod
    def read_env(cls, env_file=None, **overrides):
        super(MyEnv, cls).read_env()
        for k, v in os.environ.items():
            cls.ENVIRON.setdefault(k, v)
```

上記のように、「ENVIRONの管理を`os.environ`ではなく自前`dict`にする」「`read_env`ないで後追いで`os.environ`を取り込む」とすることで、`.env`の方を優先的に利用することが出来ます。
この実装だと、環境変数にあったとしても.envが優先されるため、ファイルの中身を利用可能です。

※問題点として、`read_env`の呼び出しが必須になります
※`read_env`を`super`経由ではなく「`setdefault`を使わない版に再実装」でも問題ないです

Answer

個人的な意見ですが、共通する変数、つまり定数のようなもののみPCの環境変数にするのが良いと思います。

実際、APIキーや、DBの情報もろもろは定数化されないはずです。

つまりkey:valueとすると、一種類のkeyに複数種類のvalueが存在することになります。

よって、プロジェクトごとの.envをおすすめします。
gitで管理しないように注意すればいいです。

やりたいこと

試したこと

代替策を渋る理由

追記（2021/07/24）

回答としての結論

理由：read_envの仕組み

無理やりする例

django-environのread_envを書き換えたクラスを用意する

関連した質問

`django-environ`のread_envを書き換えたクラスを用意する