5

質問

以下の複数のDjangosettings.pyファイルへの私のアプローチは合理的ですか（透明、安全など）？

私のアプローチ

私はとを持っていsettings.pyますsettings_local.py。settings.pyはバージョン管理下にあり、aはバージョン管理settings_local.py下にありません。最後に、利用可能な場合settings.pyはインポートを試みます。settings_local.py

このアプローチに対する私の理論は、デフォルト/安全な設定settings.pyをそのままにして、本番環境にプッシュしてデプロイできるというものです。展開時に、settings_local.py存在せず、そのローカルのみの設定は使用されません。ただし、ローカルで作業する場合settings_local.pyは存在し、そのローカルのみの設定が使用されます。

settings.py

DEBUG = False
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
)
# other settings...

try:
    from settings_local import *
except ImportError:
   pass

settings_local.py

from settings import *

DEBUG = True
MIDDLEWARE_CLASSES += (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)
# other settings...

このアプローチについての私の懸念は、両方が他方をインポートすることです。これは循環インポートとは見なされませんが、さまざまな状況下でこれらのファイルを結合することを検討することを示す指標としては適切ではないと思います。

settings_local.pyインポートする理由settings.pyは、DRYの原則を遵守しながら、すでに定義されている変数に追加できるようにするためです。たとえば、MIDDLEWARE_CLASSES完全に再定義せずにに新しいエントリを追加します。

ありがとう！

解決

最終的に、私は上記のアプローチを放棄しました。この問題を解決しようとすることは、私にとって興味深く有益なプロセスでしたが、私の統合されたアプローチには、あまりにも多くの欠点があります。

将来これを見つける人々にとって、最も適切なアプローチは、@DrTyrsaと@MarkLavinによって親切に指摘されたように、このトピックに関するwikiページで概説されている解決策の1つである可能性があります。

4

1 に答える 1

5

これは一般的なアプローチですが、適切なアプローチではありません。私は過去にこのタイプの構成を使用し、それ以来それを放棄しました。問題は、複数の開発者が一緒に作業している場合、または複数の環境（つまり、ステージングと本番）にデプロイしている場合に発生します。どちらかを選択できます

  1. 本番settings.py設定を行います。次に、各開発者は、ローカル環境をセットアップするために設定をオーバーライドする必要があります（DB設定、、DEBUG=True追加debug_toolbarなど）。これはソース管理ではないため、繰り返し作業が行われ、「自分のマシンで動作する」という種類の問題が発生します。
  2. 開発settings.py設定を行います。これで、ソース管理さlocal_settings.pyれていない本番構成の意味のある部分ができました。これにより、展開が煩雑になります。明らかに、機密情報をソース管理に入れたくありません。

ステージング環境を追加すると、これがさらに悪化します。私は、SplitSettingswikiで説明されている環境用のシンプルパッケージ編成を非常に好みます。

于 2012-04-23T20:35:32.043 に答える