2 に答える
自動ランタイム sass/compass コンパイルを回避することを選択しました。その代わりに、開発では単に "compass --watch" を使用し、Sass と生成された CSS の両方をリポジトリにコミットします。その場合、Django プロジェクトには特別な機械はまったく必要ありません。通常どおり CSS ファイルを処理するだけです。
これにはいくつかの利点があります。
- 運用サーバー インフラストラクチャと運用サーバー インフラストラクチャから可動部分の追加チャンク全体を削除します。完全な Ruby スタックに加えて、運用サーバーに Sass、Compass、およびその他の必要な gem を用意する必要はありません。運用サーバーをよりシンプルにすることは、非常に良いことです。また、純粋な Python ホスティングへのデプロイに問題はありません。
- Compass プラグインの gem バージョンなどのわずかな違いによる、開発者間、または開発と本番の間で不可解な微妙な表示の不一致はありません。誰もが同じ CSS を見ます。開発者の Compass 環境間の違いは、生成された CSS のコミット前の差分に予期しない変更としてすぐに表示されるため、すばやく検出されます。
もちろん、不利な点は、生成されたコードをレポにコミットすることであり、これは一般的に嫌われています。ただし、この結果として実際に問題が発生したことはありません。生成された CSS を直接編集しようとする人はいません。コンパスを使用していることは誰もが知っています。私たちにとって、利点は間違いなく欠点を上回っています。django-css のような統合アプローチに切り替えようという誘惑はまったくありませんでした。
あなたの最善の策は、SASSのcssコンパイルも行うdjango-compressorのフォークであるdjango-cssを使用することです。プラグインすると、compass、susy、および blueprint を通常どおり使用できます。これらは、ソース ファイルの更新バージョンが検出されるたびに django によってコンパイルされます。
編集: ep.io などの純粋な python ホストにデプロイする場合は、これらがcleverCSS (純粋な python SASS&SCSS コンパイラ) に組み込まれる方法を調査する必要があります。
編集2：
この情報は古くなっています。django-compressor は、前処理機能が組み込まれているため、最適なオプションであり、ファイルをバンドルすることもできます;)