(機械翻訳) Pyramid プロジェクトの作成¶

：ref： firstapp_chapter`で見たように、：app： Pyramid`アプリケーションを完全に手動で作成することは可能です。しかし、通常、：term： cookiecutter`を使ってbasic：app： Pyramid`：term： `project`を生成する方が便利です。

プロジェクトは少なくとも一つのPython：term： `package`を含むディレクトリです。 cookiecutterを使用してプロジェクトを作成すると、プロジェクト内に存在するパッケージ内にアプリケーションロジックを作成します。アプリケーションが非常にシンプルであっても、（1）パッケージが新しいコードでより簡単に拡張され、（2）パッケージ内に存在するアプリケーションがパッケージ内に存在しないものよりも容易に配布されます。

Pylonsプロジェクトには、プロジェクトを生成するために使用できるいくつかの：app： Pyramid cookiecuttersがあります。各CookiCutterは、構築しようとしているアプリケーションのタイプについて、さまざまな設定を前提にしています。

これらのcookiecuttersは、あなたがインストールできる `` cookiecutter``コマンドを使ってレンダリングされます。

参考

`Cookiecutterのインストール<https://cookiecutter.readthedocs.io/en/latest/installation.html> `_。

：app： Pyramid cookiecutters¶

Pylonsプロジェクトの下でリリースされたピラミッドのcookiecuttersは、いくつかの軸でお互いに異なる：

彼らが提供する永続化機構（永続化機構なし、term：SQLiteで SQLAlchemy、：term：` ZODB`）
URLをコードにマッピングするためのメカニズム（：term： URL dispatch`または：term： traversal`）
テンプレートライブラリ（：term： Jinja2、：term：` Chameleon`、または：term： Mako）

`pyramid-cookiecutter-starter <https://github.com/Pylons/pyramid-cookiecutter-starter> `_
`ピラミッド - クッキーカッター - 錬金術<https://github.com/Pylons/pyramid-cookiecutter-alchemy> `_
`pyramid-cookiecutter-zodb <https://github.com/Pylons/pyramid-cookiecutter-zodb> `_

これらのcookiecuttersには次のものがあります。

``ピラミッド - クッキーカッター - スターター ``: ：term： Jinja2、：term：` Chameleon`、または：term：テンプレート用 `` Mako`：ルーティングのためのterm： URL dispatch
``ピラミッド - クッキーカッター - 錬金術 ``: 永続ストレージのためのSQLite：term：ORMの場合は SQLAlchemy、ルーティングの場合はterm：` URL dispatch`、テンプレート化の場合は：term： Jinja2。
`` pyramid-cookiecutter-zodb``: ：term：永続的なストレージのための ZODB、：term：ルーティングのための` traversal`、および：term：テンプレート化のための Chameleon

プロジェクトの作成¶

：ref： installing_chapter`では、 venv``コマンドで仮想的なPython環境を作成しました。仮想環境ディレクトリ ` env``を呼び出し、環境変数 `` VENV``をそのパスに設定しました。

私たちは次のように仮定します：ref： `以前にインストールされたcookiecutter <cookiecutters> `をインストールの指示に従ってインストールします。

プロジェクトを開始するには `` pyramid-cookiecutter-starter``を選択します。 `` cookiecutter``を呼び出すと、プロジェクトを表すディレクトリが作成されます。

現在の作業ディレクトリは `` VENV``の値であると仮定します。

すべてのプラットフォームで、cookiecutterを使用してプロジェクトを生成します。

$ cookiecutter gh:Pylons/pyramid-cookiecutter-starter --checkout 1.9-branch

最初の項目の入力を求められたら、returnキーを押してデフォルトの `` yes``を受け入れます。

You've cloned ~/.cookiecutters/pyramid-cookiecutter-starter before.
Is it okay to delete and re-clone it? [yes]: yes
project_name [Pyramid Scaffold]: myproject
repo_name [myproject]: myproject
Select template_language:
1 - jinja2
2 - chameleon
3 - mako
Choose from 1, 2, 3 [1]: 1

次に、次のコマンドを実行します。

UNIXの場合：

# Reset our environment variable for a new virtual environment.
$ export VENV=~/env/myproject/env
# Change directory into your newly created project.
$ cd myproject
# Create a new virtual environment...
$ python3 -m venv $VENV
# ...where we upgrade packaging tools.
$ env/bin/pip install --upgrade pip setuptools

またはWindowsの場合：

# Reset our environment variable for a new virtual environment.
c:\> set VENV=c:\env\myproject\env
# Change directory into your newly created project.
c:\> cd myproject
# Create a new virtual environment...
c:\myproject> python -m venv %VENV%
# ...where we upgrade packaging tools.
c:\myproject> %VENV%\Scripts\pip install --upgrade pip setuptools

`` cookiecutter``コマンドを実行すると、 `` myproject``という名前のディレクトリが作成されます。そのディレクトリは：term： project`ディレクトリです。そのディレクトリにある ` setup.py``ファイルは、アプリケーションを配布したり、展開や開発のためにアプリケーションをインストールしたりするために使用できます。

`` .ini``という名前の `` .ini``ファイルがプロジェクトディレクトリに作成されます。この `` .ini``ファイルを使用して、サーバの設定、アプリケーションの実行、アプリケーションのデバッグを行います。インタラクティブなデバッガと開発用に最適化された設定を可能にする設定が含まれています。

`` production.ini``という別の `` .ini``ファイルもプロジェクトディレクトリに作成されます。これには、（不適切なアクセスと開示を防ぐための）対話型デバッガを無効にし、多くのデバッグ設定を無効にする構成が含まれています。このファイルを使用すると、アプリケーションを本番環境に置くことができます。

`` myproject``プロジェクトディレクトリには、非常に単純な：app： Pyramid`サンプルコードを保持するPython：term： package`を表す `` myproject``という別のサブディレクトリがあります（ケースの違いに注意してください）。ここで、アプリケーションのPythonコードとテンプレートを編集します。

このプロジェクトは、仮想環境ディレクトリの隣のディレクトリに作成しました。ただし、これは必須ではありません。プロジェクトディレクトリは、ファイルシステムのどこにでも置くことができます。特殊な"web server "ディレクトリに置く必要はありません。あなたは仮想環境ディレクトリ内に置くことができます。作者は主にLinuxを使い、 ``〜/ projects``ディレクトリ内に作成したプロジェクトディレクトリを置く傾向があります。 Windowsでは、プロジェクトディレクトリを空白文字が含まれていないディレクトリに置くことをお勧めします。そのため、含まれているパス、つまり「マイドキュメント」を回避することが賢明です。結果として、作者はWindowsを使うときには、自分のプロジェクトを `` C：projects``に置くだけです。

警告

Pythonの標準ライブラリコンポーネントと同じ名前のプロジェクトを作成するには、 `` cookiecutter``を使わないでください。特に、これは `` site``や `` test``という名前を使わないでください。両方ともPythonの標準ライブラリパッケージと矛盾します。また、ピラミッドそのものと衝突する名前の「ピラミッド」を使わないでください。

新しく開発されたプロジェクトをインストールする¶

開発のために新しく作成したプロジェクトをインストールするには、新しく作成したプロジェクトディレクトリに `` cd``を実行し、ref： installing_chapter`の中で作成したterm： virtual environment`のPythonインタプリタを使用して ` pip install -e .``は、現在のディレクトリ（ .`）に開発モード（` `-e``は"編集可能"用）でプロジェクトをインストールします。

`` setup.py``という名前のファイルはcookiecutter生成のプロジェクトディレクトリのルートにあります。あなたが呼び出す `` python``は、あなたの仮想Python環境の `` bin``（または `` Scripts``）ディレクトリにあるものでなければなりません。あなたの端末の現在の作業ディレクトリ*は新しく作成されたプロジェクトディレクトリでなければなりません。

UNIXの場合：

$ $VENV/bin/pip install -e .

またはWindowsの場合：

c:\env\myproject> %VENV%\Scripts\pip install -e .

UNIXでこのコマンドを実行したときに出力されなかったものを以下に示します。

  Running setup.py develop for myproject
Successfully installed Jinja2-2.8 Mako-1.0.6 MarkupSafe-0.23 \
PasteDeploy-1.5.2 Pygments-2.1.3 WebOb-1.7.0 myproject pyramid-1.7.3 \
pyramid-debugtoolbar-3.0.5 pyramid-jinja2-2.7 pyramid-mako-1.0.2 \
repoze.lru-0.6 translationstring-1.3 venusian-1.0 waitress-1.0.1 \
zope.deprecation-4.2.0 zope.interface-4.3.3

これは仮想環境インタプリタのライブラリセットにプロジェクトを表す：term： distribution`をインストールし、 import``文や pserve`、` pshell``などの他のコンソールスクリプトで見つけることができます、 ` proutes``、 `` pviews``などがあります。

アプリケーションのテストの実行¶

アプリケーションの単体テストを実行するには、まずテストの依存関係をインストールする必要があります。

UNIXの場合：

$ $VENV/bin/pip install -e ".[testing]"

Windowsの場合：

c:\env\myproject> %VENV%\Scripts\pip install -e ".[testing]"

テスト要件がインストールされたら、あなたの仮想環境の `` bin``ディレクトリにインストールされた `` py.test``コマンドを使ってテストを実行することができます。

UNIXの場合：

$ $VENV/bin/py.test -q

Windowsの場合：

c:\env\myproject> %VENV%\Scripts\py.test -q

次に、UNIXでのテスト実行の出力例を示します。

$ $VENV/bin/py.test -q
..
2 passed in 0.47 seconds

テスト自体は `` cookiecutter``生成プロジェクトの `` tests.py``モジュールにあります。 `` pyramid-cookiecutter-starter`` cookiecutterによって生成されたプロジェクトでは、2つのサンプルテストしか存在しません。

注釈

`` -q``オプションは `` py.test``コマンドに渡され、出力をドットのストリームに制限します。 `` -q``を渡さないと、冗長なテスト結果出力が表示されます（通常はそれほど役に立ちません）。

あるいは、テストカバレッジを表示する場合は、 `` --cov``オプションを `` py.test``に渡します：

$ $VENV/bin/py.test --cov -q

Cookiecuttersには、 `` py.test``とテストカバレッジのデフォルト設定が含まれています。これらの設定ファイルはパッケージのルートにある `` pytest.ini``と `` .coveragerc``です。これらのデフォルトがなければ、テストとカバレッジを実行するモジュールへのパスを指定する必要があります。

$ $VENV/bin/py.test --cov=myproject myproject/tests.py -q

参考

：ref： pytest：usage`のpy.testのドキュメントを参照するか、 `py.test -h``を呼び出してその完全なオプションセットを見てください。

プロジェクトアプリケーションの実行¶

参考

：ref： `pserve --helpの出力も参照してください。 <pserve_script> `。

プロジェクトを開発用にインストールしたら、生成された設定ファイルに対して `` pserve``コマンドを使って表すアプリケーションを実行できます。私たちの場合、このファイルの名前は `` development.ini``です。

UNIXの場合：

$ $VENV/bin/pserve development.ini

Windowsの場合：

c:\env\myproject> %VENV%\Scripts\pserve development.ini

UNIXでの `` pserve``の実行結果のサンプルを以下に示します：

$ $VENV/bin/pserve development.ini
Starting server in PID 77171.
Serving on http://localhost:6543
Serving on http://localhost:6543

Pyramidと同じマシン上で動作するブラウザのみがPyramidアプリケーションにアクセスできるようにアクセスが制限されています。しかし、同じネットワーク上の他のマシンへのアクセスを開きたい場合は、 `` development.ini``ファイルを編集し、 `` [server：main] ``セクションの `` listen``値を置き換えてください。 `` localhost：6543``から `` *：6543``に変更します（これは `` 0.0.0.0:6543 [::]：6543``と同じです）。例えば：

[server:main]
use = egg:waitress#main
listen = *:6543

これで、アプリケーションを起動するために `` pserve``を使うと、 `` localhost``へのリクエストだけでなく、あなたのシステムが所有するすべての* IPアドレスに対するリクエストに応答します。これは `` http：//0.0.0.0：6543で提供する `` 0.0.0.0``を意味します。サーバは `` 127.0.0.1``と任意の外部IPアドレスに対する要求に応答します。たとえば、システムが外部IPアドレス「192.168.1.50」を持つように設定されている可能性があります。そうであれば、Pyramidと同じシステム上で動作しているブラウザを使うと、 `` http：//127.0.0.1：6543 / ``と `` http： /192.168.1.50：6543 / ``しかし、同じネットワーク上の他のコンピュータの*他の人も、http：//192.168.1.50：6543 / ``にアクセスして、ブラウザのPyramidアプリケーションにアクセスすることができます。 IPv6を使用している場合も同様です。 `` [::] ``は `` 0.0.0.0``と同じですが、IPv6プロトコルの場合と同じです。

`` development.ini``ファイルの同じ部分を変更することで、サーバが動作するポートを変更することができます。たとえば、 `` development.ini``ファイルの `` [server：main] ``セクションを `` listen = localhost：8080``に変更すると、 `` listen = localhost：ポート6543の代わりにポート8080に接続します。

`` Ctrl-C``（またはWindowsでは `` Ctrl-Break``）を押すことで、このように起動したサーバをシャットダウンすることができます。

プロジェクトがcookiecutterから作成されたときにPyramidアプリケーションを実行するために使用されるデフォルトのサーバーの名前はterm： Waitress`です。このサーバは ` pserve``を実行するときに `` Serving on ... ``行を表示します。これは非常に簡単なので、開発中にこのサーバーを使用することをお勧めします。軽量生産にも使用できます。アプリケーションを別のサーバーの下に置くことは、特にPython Web開発にまだ慣れていない場合には、デフォルトサーバーで開発作業を行うまではお勧めしません。 Python Webサーバーの設定は複雑になる可能性があります。アプリケーションをデフォルト環境で動作させる前に、アプリケーションを最適化しようとするか、「生産のように」するという確信を得てください。実際に開発を始めることなく、何時間もデフォルト以外のサーバーを設定しようとしたら、横行することは非常に簡単です。 Python Webサーバーに関する優れた点の1つは、互換性がほとんどないため、アプリケーションがデフォルトのサーバーで動作する場合、最終的に別のサーバーを使用するように選択すると、他のサーバー上で動作することがほぼ確実になります。今は心配しないでください。

起動プロセスの詳細については、：ref： `startup_chapter`を参照してください。起動と実行時の動作に影響する環境変数と設定ファイルの設定の詳細については、：ref： `environment_chapter`を参照してください。

コードのリロード¶

開発中、 `` --reload``オプションを使って `` pserve``を実行すると便利なことがよくあります。 `` --reload``が `` pserve``に渡されると、あなたのプロジェクトが使用するPythonモジュールの変更により、サーバが再起動します。これは、一般的には、：app： `Pyramid`アプリケーション内で作られたPythonコードの変更が、サーバが再起動されるまで有効にならないため、開発が容易になります。

たとえば、UNIXの場合：

$ $VENV/bin/pserve development.ini --reload
Starting subprocess with file monitor
Starting server in PID 16601.
Serving on http://localhost:6543
Serving on http://localhost:6543

プロジェクトの `` .py``ファイルや `` .ini``ファイルのいずれかを変更すると、自動的にサーバが再起動します：

development.ini changed; reloading...
-------------------- Restarting --------------------
Starting server in PID 16602.
Serving on http://localhost:6543
Serving on http://localhost:6543

テンプレートファイル（ `` .pt`や `` .mak``ファイルなど）を変更しても、サーバは再起動しません。テンプレートファイルの変更は、 `` development.ini``ファイルの `` pyramid.reload_templates``の設定が `` true``である限り、サーバを再起動する必要はありません。この設定が `` true``のときにテンプレートファイルに加えられた変更は、サーバを再起動しなくてもすぐに有効になります。

アプリケーションの表示¶

アプリケーションが `` pserve``で実行されると、あなたのブラウザの `` http：// localhost：6543 / ``にアクセスすることができます。次の画像に表示されているようなものがブラウザに表示されます。

これは、ブラウザで修正された `` cookiecutter``の `` pyramid-cookiecutter-starter``アプリケーションを訪れたときにデフォルトで表示されるページです。

デバッグツールバー¶

ページの右上に：app： `Pyramid`ロゴをクリックすると、新しいターゲットウィンドウが開き、開発中にさまざまな細かい点を提供するデバッグツールバーが表示されます。このロゴは、アプリケーション開発中に：app： `Pyramid`によって提供されるすべてのHTMLページの上に浮動表示され、必要に応じてツールバーを表示することができます。

ページの右上にピラミッドのロゴが表示されない場合は、デバッグアクセスのないシステムからブラウズしていることを意味します。デフォルトでは、セキュリティ上の理由から、 `` localhost``（ `` 127.0.0.1``）に由来するブラウザだけがデバッグツールバーを見ることができます。リモートシステム上のブラウザがサーバにアクセスできるようにするには、 `` development.ini``ファイルの `` [app：main] ``セクションに `` debugtoolbar.hosts = X .XXX ``。たとえば、あなたのPyramidアプリケーションがリモートシステム上で動作していて、IPアドレスが `` 192.168.1.1``のホストからブラウズしている場合は、システムがピラミッドに接続しているときにツールバーを有効にするために、：

[app:main]
# .. other settings ...
debugtoolbar.hosts = 192.168.1.1

デバッグツールバーでできることの詳細については、pyramid_debugtoolbarの：ref： `ドキュメントを参照してください。 <toolbar:overview> `。

アプリケーションを実行するために `` development.ini`` iniファイルの代わりに `` production.ini``ファイルを使用すると、デバッグツールバーは表示されません（また、すべてのデバッグはオフになります）。

`` development.ini``を編集して行をコメントアウトすることで、デバッグツールバーをオフにすることもできます。たとえば、次の代わりに：

[app:main]
# ... elided configuration
pyramid.includes =
    pyramid_debugtoolbar

`` pyramid_debugtoolbar``行の先頭にハッシュマークをつけます：

[app:main]
# ... elided configuration
pyramid.includes =
#    pyramid_debugtoolbar

次に、アプリケーションを再起動して、ツールバーがオフになっていることを確認します。

`` pyramid_debugtoolbar``行をコメントアウトすると、 ``＃ `` *は最初の列になければなりません。他の場所に置いて、アプリケーションを再起動しようとすると、次のようなエラーが返されます。

ImportError: No module named #pyramid_debugtoolbar

プロジェクトの構造¶

`` pyramid-cookiecutter-starter`` cookiecutterは、：term： project`（ myproject``という名前）を生成しました。これはPython：term： package`を含みます。パッケージは `` myproject``とも呼ばれます。 cookiecutterは、その名前を共有するパッケージを含むプロジェクトを生成します。

All：app： Pyramid `` cookiecutter``で生成されたプロジェクトは、同様の構造を共有しています。生成された `` myproject``プロジェクトは以下のディレクトリ構造を持っています：

myproject/
├── .coveragerc
├── CHANGES.txt
├── MANIFEST.in
├── myproject
│   ├── __init__.py
│   ├── static
│   │   ├── pyramid-16x16.png
│   │   ├── pyramid.png
│   │   └── theme.css
│   ├── templates
│   │   ├── layout.jinja2
│   │   └── mytemplate.jinja2
│   ├── tests.py
│   └── views.py
├── README.txt
├── development.ini
├── production.ini
├── pytest.ini
└── setup.py

`` myproject``：term： Project¶

`` myproject``：term： project`ディレクトリは、あなたのアプリケーションの配布と展開ラッパーです。これはアプリケーションを表す ` myproject`：term： `package`とアプリケーションの記述、実行、テストに使用されるファイルの両方を含みます。

`` .coveragerc``はテストを実行するときにカバレッジを設定します。
`` CHANGES.txt``はあなたがアプリケーションに加えた変更を記述します。これは通常：term： `reStructuredText`形式で書かれています。
`` MANIFEST.in``は：term： distutils "マニフェスト"ファイルで、` `python setup.py sdist``が実行されたときにパッケージのソース配布物に含まれるファイル名を指定します。
`` README.txt``は一般的なアプリケーションを記述します。これは通常：term： `reStructuredText`形式で書かれています。
`` development.ini``は、開発中にアプリケーションを実行するために使用できる：term： `PasteDeploy`設定ファイルです。
`` production.ini``は、プロダクション設定でアプリケーションを実行するために使用できる：term： `PasteDeploy`設定ファイルです。
`` pytest.ini``はテストを実行するための設定ファイルです。
`` setup.py``は、アプリケーションのテストと配布に使用するファイルです。 term： setuptools` `setup.py``ファイルです。

`` development.ini``¶

`` development.ini``ファイルは：term： PasteDeploy`設定ファイルです。その目的は、 ` pserve``を起動したときに実行するアプリケーションと、そのアプリケーションに提供されるデプロイメント設定を指定することです。

生成された `` development.ini``ファイルは次のようになります：

###
# app configuration
# https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html
###

[app:main]
use = egg:myproject

pyramid.reload_templates = true
pyramid.debug_authorization = false
pyramid.debug_notfound = false
pyramid.debug_routematch = false
pyramid.default_locale_name = en
pyramid.includes =
    pyramid_debugtoolbar

# By default, the toolbar only appears for clients from IP addresses
# '127.0.0.1' and '::1'.
# debugtoolbar.hosts = 127.0.0.1 ::1

###
# wsgi server configuration
###

[server:main]
use = egg:waitress#main
listen = localhost:6543

###
# logging configuration
# https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/logging.html
###

[loggers]
keys = root, myproject

[handlers]
keys = console

[formatters]
keys = generic

[logger_root]
level = INFO
handlers = console

[logger_myproject]
level = DEBUG
handlers =
qualname = myproject

[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic

[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s:%(lineno)s][%(threadName)s] %(message)s

このファイルには、 `` [app：main] ``、 `` [server：main] ``、その他のロギング設定に関連するセクションが含まれています。

`` [app：main] ``セクションは：app： Pyramid`アプリケーションの設定を表します。 ` use``設定は、 `` [app：main] ``セクションに存在する唯一の設定です。デフォルト値の `` egg：myproject``は、私たちのmyprojectプロジェクトが提供されるべきアプリケーションを含んでいることを示します。このセクションに追加された他の設定は、パッケージの `` __init __。py``モジュールの `` main``という名前の関数にキーワード引数として渡されます。このセクションにさらに設定を追加することで、アプリケーションに起動時の構成パラメータを提供できます。

参考

このセクションの `` use = egg：myproject``値の意味については、ref： `pastedeploy_entry_points`を参照してください。

`` [app：main] ``セクションの `` pyramid.reload_templates``の設定は、：app： Pyramid`固有の設定で、フレームワークに渡されます。存在し、その値が ` true``の場合、サポートされているテンプレートの変更では、アプリケーションの再起動を検出する必要はありません。詳細は、ref： `reload_templates_section`を参照してください。

警告

`` pyramid.reload_templates``オプションは、実稼働アプリケーションではオフにする必要があります。これは、テンプレートレンダリングが有効になっているときに遅くなるためです。

`` [app：main] ``セクションの `` pyramid.includes`の設定は、Pyramidに別のパッケージの設定を "含める"ように指示します。この場合、 `` pyramid.includes = pyramid_debugtoolbar``はPyramidに `` pyramid_debugtoolbar``パッケージの設定を含めるように指示します。これは、開発モードのデバッグパネルをオンにします。これは、画面の右上に：app： `Pyramid`ロゴをクリックすることで開くことができます。デバッグツールバーを含めることで、エラーが発生したときに対話的に例外をデバッグすることも可能になります。

このセクションには、app： `Pyramid`アプリケーションの実行時動作をデバッグしたり影響を与えたりするためのさまざまな設定があります。これらの設定の詳細については、ref： `environment_chapter`を参照してください。

`` [app：main] ``の中の `` main``という名前は、これがこの設定ファイルに対して呼び出されたときに `` pserve``が実行するデフォルトのアプリケーションであることを示します。 `` main``という名前は、PasteDeployがデフォルトのアプリケーションであることを示すために使用される規約です。

設定ファイルの `` [server：main] セクションは、TCPポート6543をリッスンするWSGIサーバを設定します。ローカルホストのみ（ `` 127.0.0.1）でリッスンするように設定されています。

``＃logging configuration``の後のセクションはPythonの標準ライブラリを表しています：アプリケーションのmod： logging`モジュール設定。これらのセクションは `ロギングモジュールの設定ファイル設定エンジン<https://docs.python.org/2/howto/logging.html#configuring-logging> ` pserve``や `` pshell``コマンドが実行されたときに `_ 'を返します。デフォルト設定では、アプリケーションログ出力が端末の標準エラー出力に送信されます。ロギング設定の詳細については、：ref： `logging_chapter`を参照してください。

：term：ミドルウェア、alternate：term： WSGI`など、この .ini``ファイルに入れることができる他のタイプのものの詳細については、：term： PasteDeploy`のドキュメントを参照してください。サーバー実装。

production.ini¶

`` production.ini``ファイルは：term： PasteDeploy`設定ファイルで、 development.ini``によく似ています。ただし、デバッグツールバーを無効にし、WARNレベルを超えるすべてのログメッセージをフィルタリングします。また、テンプレートが変更されたときに自動的にリロードされないように、またすべてのデバッグオプションをオフにするようなテンプレート開発オプションもオフにします。このファイルは、アプリケーションを実稼働環境に置くときに ` development.ini``の代わりに使うのに適しています。

アプリケーションをベンチマークしてプロダクションに入れるには、 `` production.ini``（そして `` development.ini``ではなく*）を使うことが重要です。 `` development.ini``は開発に役立つデバッグツールバーを使ってシステムを設定しますが、このツールバーを組み込むことでページレンダリング時間が一桁以上遅くなります。デバッグツールバーは、正しく構成されていないと、セキュリティリスクの可能性もあります。

`` MANIFEST.in``¶

`` MANIFEST.in``ファイルは：term： distutils`設定ファイルで、pythonプロジェクトの：term： distribution`が `` pythonを実行するときに作成されるときに含めるべき非Pythonファイルを指定します。 setup.py sdist``を実行します。デフォルトの `` MANIFEST.in``に含まれている情報のため、Pyramidプロジェクトのsdistには `` .txt``ファイル、 `` .ini``ファイル、 `` .rst``ファイル、グラフィックファイル、テンプレートファイル、 `` .py``ファイルなどがあります。 `` MANIFEST.in``の構文と使い方の詳細については、https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-templateを参照してください。

`` MANIFEST.in``ファイルがないか、ソースコードをバージョン管理リポジトリにチェックしなくても、 `` setup.py sdist``は* Pythonソースファイル*（ `` .py``で終わるファイルのみ） `` python setup.py sdist`で生成されたtarballに変換します。たとえば、プロジェクトがsetuptools互換のソース管理システムにチェックインされておらず、プロジェクトディレクトリに `` MANIFEST.in``ファイルが含まれていない場合、 `` sdist``マシンに ` * .pt``ファイルの場合、 `myproject / templates / mytemplate.pt``ファイルは生成されたtarballに含まれません。

Pyramid cookiecuttersによって生成されるプロジェクトには、デフォルトの `` MANIFEST.in``ファイルが含まれています。 `` MANIFEST.in``ファイルは生成されたtarballに `` * .pt``、 `` * .css``、 `` * .js``のようなファイルを含めるように宣言しています。プロジェクトの `` MANIFEST.in``に指定されたファイル以外の拡張子を持つファイルをインクルードし、setuptoolsと互換性のあるバージョン管理システムを使用していない場合は、 `` MANIFEST.in` `ファイルを開き、新しいファイルをインクルードするのに必要なステートメントを含めます。これを行う方法の詳細については、https://docs.python.org/2/distutils/sourcedist.html#principleをご覧ください。

あなたのプロジェクトから `` MANIFEST.in``を削除して、バージョン管理システムにチェックインされたすべてのファイルを生成されたtarballに入れさせるsetuptools機能に依存することもできます。これを可能にするには、アプリケーションのPythonファイルと共に配布するすべてのファイルをSubversionにチェックインしてください。これを実行した後、 `` setup.py sdist``を再実行すると、バージョン管理システムにチェックインされたすべてのファイルがtarballに含まれます。 Subversionを使用せず、代わりに別のバージョン管理システムを使用する場合は、この動作が適切に動作するように `` setuptools-git``や `` setuptools-hg``などのsetuptoolsアドオンをインストールする必要があります。

`` setup.py``¶

`` setup.py``ファイルは：term： `setuptools`セットアップファイルです。これは、パッケージの依存関係をインストールするための要件を定義したり、アプリケーションを配布したりテストしたりするために使用されます。

注釈

`` setup.py``は、Python開発者が再利用可能なコードを配布するために使用する事実上の標準です。 `` setup.py``ファイルとその使い方については、 `` Python Packaging User Guide」を参照してください。 <https://packaging.python.org/> _と Setuptoolsのドキュメント<http://pythonhosted.org/setuptools/> `_。

生成された `` setup.py``は次のようになります：

import os

from setuptools import setup, find_packages

here = os.path.abspath(os.path.dirname(__file__))
with open(os.path.join(here, 'README.txt')) as f:
    README = f.read()
with open(os.path.join(here, 'CHANGES.txt')) as f:
    CHANGES = f.read()

requires = [
    'plaster_pastedeploy',
    'pyramid',
    'pyramid_jinja2',
    'pyramid_debugtoolbar',
    'waitress',
]

tests_require = [
    'WebTest >= 1.3.1',  # py3 compat
    'pytest',
    'pytest-cov',
]

setup(
    name='myproject',
    version='0.0',
    description='MyProject',
    long_description=README + '\n\n' + CHANGES,
    classifiers=[
        'Programming Language :: Python',
        'Framework :: Pyramid',
        'Topic :: Internet :: WWW/HTTP',
        'Topic :: Internet :: WWW/HTTP :: WSGI :: Application',
    ],
    author='',
    author_email='',
    url='',
    keywords='web pyramid pylons',
    packages=find_packages(),
    include_package_data=True,
    zip_safe=False,
    extras_require={
        'testing': tests_require,
    },
    install_requires=requires,
    entry_points={
        'paste.app_factory': [
            'main = myproject:main',
        ],
    },
)

`` setup.py``ファイルはsetuptoolsの `` setup``関数を呼び出します。これは、コマンドラインで `` pip``に渡される引数に応じて様々なことを行います。

この関数呼び出しの引数の中に、アプリケーションに関する情報が保持されます。 setuptoolsのセットアップファイルに関するすべてのことを説明するのは、このドキュメントの範囲を超えていますが、このセクションでは、このファイルに存在するものについての旋風のツアーを提供します。

アプリケーションの名前には任意の文字列を使用できます。 `` name``フィールドに指定されています。バージョン番号は `` version``値で指定されます。 `` description``フィールドに簡単な説明があります。 `` long_description``は、従来、一緒に追加された `` README``と `` CHANGES``ファイルの内容です。 `` classifiers``フィールドは、 `` Trove分類子のリストです<https://pypi.org/pypi?%3Aaction=list_classifiers>あなたのアプリケーションを記述する。 `` author``と `` author_email``は、おそらく何も記述する必要のないテキストフィールドです。 `` url``はアプリケーションプロジェクトのURLを指すフィールドです（存在する場合）。 `` packages = find_packages（） ``は、アプリケーションをパッケージ化するときに、プロジェクト内のすべてのパッケージが見つかるようにします。 `` include_package_data``には、バージョンコントロールにチェックインされているアプリケーションがパッケージされている場合、非Pythonファイルが含まれます。 `` zip_safe = False``は、このパッケージが圧縮された卵として安全に使用できないことを示します。代わりに、常にディレクトリとして解凍されます。これはより便利です。 `` install_requires``は、このパッケージが `` pyramid``パッケージに依存していることを示します。 `` extras_require``は、テストの実行に必要なものを定義するPython辞書です。 `` development.ini``ファイルの議論で `` entry_points``を調べました。このファイルはプロジェクトのアプリケーションを表す `` main``エントリーポイントを定義します。

通常は、アプリケーションを他の人に配布するとき、Pythonパッケージの依存関係を追加するとき、またはあなたのアプリケーションをバージョン管理するときに `` setup.py``ファイルの内容について考えるだけです。楽しみのために、今すぐこのコマンドを試すことができます：

$ $VENV/bin/python setup.py sdist

これは `` myproject-0.0.tar.gz``という名前の `` dist``サブディレクトリにアプリケーションのtarballを作成します。アプリケーションをインストールして使用したい他の人にこのtarballを送ることができます。

`` myproject``：term： Package¶

`` myproject``：term： package`は myproject`：term：` project`の中にあります。を含む：

`` __init __。py``ファイルは、これがPython：term： package`であることを示します。また、 ` pserve``、 `` pshell``、 `` pviews``などのコマンドのエントリポイントとして使用される `` main``関数を含む、ユーザがアプリケーションを動かせるようにするコードも含まれています。
`` templates``ディレクトリ：term： `Jinja2`（または他のタイプの）テンプレートを含んでいます。
アプリケーション用のユニットテストコードを含む `` tests.py``モジュールです。
アプリケーションのビューコードを含む `` views.py``モジュールです。

これらは純粋にcookiecutterによって確立された慣例です。：app： `Pyramid`はあなたが何か特別な方法で物事の名前を書いていると主張していません。しかし、Pyramidの標準に従って名前を付けることは、一般的には良い考えです。そのため、他のPyramid開発者は、ヘルプが必要なときに素早くコードをスピードアップできます。

`` init 。py``¶

アプリケーションを設定し、term： PasteDeploy` .ini``ファイルで使用するエントリポイントを宣言する小さなPythonモジュールが必要です。これは ` __init __。py``という名前のファイルです。 `` __init __。py``の存在は、それを含むディレクトリが* package *であることをPythonに知らせます。

from pyramid.config import Configurator


def main(global_config, **settings):
    """ This function returns a Pyramid WSGI application.
    """
    config = Configurator(settings=settings)
    config.include('pyramid_jinja2')
    config.add_static_view('static', 'static', cache_max_age=3600)
    config.add_route('home', '/')
    config.scan()
    return config.make_wsgi_app()

1行目は：term： Configurator`クラスを：mod： pyramid.config`からインポートします。
4-12行目では：app： Pyramid WSGIアプリケーションを返す` main``という名前の関数を定義しています。この関数は、 ` pserve``を実行した結果、：term： `PasteDeploy`フレームワークによって呼び出されるようになっています。

この機能では、アプリケーション構成が実行されます。

7行目は：term： `Configurator`のインスタンスを作成します。

8行目は、Jinja2テンプレートバインディングのサポートを追加し、レンダラーを `` .jinja2``拡張子で指定できるようにします。

9行目はstaticビューを登録します。これは、 `` myproject：static``：term： asset specification`（ myproject``パッケージの `static``ディレクトリ）のファイルを提供します。

10行目は：term： route`を設定に追加します。このルートは後で ` views``モジュールのビューで使用されます。

11行目は `` config.scan（） ``を呼び出します。これは、パッケージ内の他の場所で宣言されたビュー登録を受け取ります（この場合、 `` views.py``モジュール内にあります）。

12行目は：term： `WSGI`アプリケーションを関数の呼び出し側（Pyramidのpserve）に返します。

`` views.py``¶

a：app： Pyramid`アプリケーションの大部分は、* view callables *によって行われます。 A：term： `view callable`は、app： Pyramid`ウェブアプリケーション開発者の主なツールです。：term： request`を受け取り、：term： response`を返すコードです。

from pyramid.view import view_config


@view_config(route_name='home', renderer='templates/mytemplate.jinja2')
def my_view(request):
    return {'project': 'MyProject'}

4行目〜6行目は、 `` my_view``という名前の `` callable``を定義して登録します。 `` my_view``という名前の関数は、 `` __init __。py``の `` config.scan（）行によって処理される `` view_config``デコレータで装飾されています。 view_configデコレータは、 `` home``という名前のa：term： `ルート`がマッチしたときに、このビューが見つかると主張します。私たちの場合、私たちの `` __init __。py``は `` home``という名前のルートをURLパターン `` / ``にマップするので、訪問者がルートURLを訪れるとこのルートが一致します。 view_configデコレータは、レンダラーの名前を指定します。この場合、ビューの結果をレンダリングするために使用されるテンプレートです。この特定のビュー宣言は `` templates / mytemplate.pt``を指しています。これは `` myproject``の `` templates``ディレクトリ内の `` mytemplate.pt``ファイルを指定する `` asset specification``です： ``パッケージ。資産仕様は、 `` myproject：templates / mytemplate.pt``として指定されている可能性もあります。先頭のパッケージ名とコロンはオプションです。指されるテンプレートファイルはa：term： `Jinja2`テンプレートファイル（` `templates / my_template.jinja2）です。

このビュー呼び出し可能関数は、：term： request`という単一の情報を渡します。 * request *は、サーバーへのブラウザーの要求を表す：term： `WebOb` `Request``クラスのインスタンスです。

このビューは、テンプレート上で：term： `renderer`を呼び出すように設定されています。ビューが返す辞書（6行目）は、レンダラーがHTMLを生成するときにテンプレートに代入する値を提供します。次に、レンダラーは：term： `response`でHTMLを返します。

注釈

辞書は値を：term： template sに提供します。

注釈

アプリケーションがcookiecutterの：ref： default development.iniで実行されているとき<myproject_ini> `configuration、：ref：`ロギングが設定されています<myproject_ini_logging> `デバッグを助ける。例外が発生した場合、起動メッセージの後にキャッチされないトレースバックが表示されます：ref： `サーバを実行しているコンソール<running_the_project_application> `。また、 ` print（） ``文をデバッグのためにアプリケーションに挿入して、このコンソールに出力を送ることもできます。

注釈

`` development.ini``には、テンプレートがどのように再ロードされるかを制御する設定があります。 `` pyramid.reload_templates``です。

CookieCutterの `` development.ini``のように `` True``に設定すると、変更されたテンプレートはサーバを再起動せずに自動的にリロードされます。開発中は便利ですが、テンプレートのレンダリング速度が遅くなります。
`` False``（デフォルト値）に設定されている場合、テンプレートを変更するには、テンプレートをリロードするためにサーバを再起動する必要があります。プロダクションアプリケーションは、 `` pyramid.reload_templates = False``を使うべきです。

参考

ビュー、レンダラー、およびテンプレートがどのように関係し協力するかについての詳細は、：ref： `views_which_use_a_renderer`を参照してください。

参考

Pyramidは、変更されたPythonファイルを動的にリロードすることもできます。参照：ref： `reloading_code`を参照してください。

参考

：ref： `debug_toolbar`も参照してください。これは、アプリケーション内部へのインタラクティブなアクセスを提供し、例外が発生した場合、Pythonインタプリタからのトレースバック実行スタックフレームへのインタラクティブなアクセスを可能にします。

「静的」¶

このディレクトリには、 `` layout.jinja2``テンプレートをサポートする静的資産が含まれています。それはCSSと画像を含んでいます。

`` templates / layout.jinja2``¶

これが基本レイアウトの内容です。これは、コンテンツブロックのための単一のマーカーを含んでいます。他のテンプレートはコンテンツを継承し、Webアプリケーションのレイアウトを提供します。その内容はここに表示するには長すぎますが、ここに抜粋があります：

          <div class="col-md-10">
            {% block content %}
                <p>No content</p>
            {% endblock content %}
          </div>

`` templates / mytemplate.jinja2``¶

これはプロジェクトに存在するcontent：term： Jinja2`テンプレートです。これは、 ` views.py``ファイルで呼び出し可能な `` my_view``ビューの `` renderer``として `` @ view_config``を呼び出すことによって参照されます。レンダラの詳細については：ref： views_which_use_a_renderer`を参照してください。 ` layout.jinja2``が提供するHTMLを継承（"extend "）し、コンテンツブロックを独自のコンテンツに置き換えます。

{% extends "layout.jinja2" %}

{% block content %}
<div class="content">
  <h1><span class="font-semi-bold">Pyramid</span> <span class="smaller">Starter project</span></h1>
  <p class="lead">Welcome to <span class="font-normal">MyProject</span>, a&nbsp;Pyramid application generated&nbsp;by<br><span class="font-normal">Cookiecutter</span>.</p>
</div>
{% endblock content %}

テンプレートは、ビュー設定によってアクセスされ、使用されることがあります。 ref： templates_used_directly`と：ref： templates_used_as_renderers`を参照してください。

`` tests.py``¶

`` tests.py``モジュールにはアプリケーションのテストが含まれています。

import unittest

from pyramid import testing


class ViewTests(unittest.TestCase):
    def setUp(self):
        self.config = testing.setUp()

    def tearDown(self):
        testing.tearDown()

    def test_my_view(self):
        from .views import my_view
        request = testing.DummyRequest()
        info = my_view(request)
        self.assertEqual(info['project'], 'MyProject')


class FunctionalTests(unittest.TestCase):
    def setUp(self):
        from myproject import main
        app = main({})
        from webtest import TestApp
        self.testapp = TestApp(app)

    def test_root(self):
        res = self.testapp.get('/', status=200)
        self.assertTrue(b'Pyramid' in res.body)

このサンプルの `` tests.py``ファイルには、ユニットテストと機能テストが1つずつあります。これらのテストは `` py.test -q``を実行すると実行されます。アプリケーションをビルドするときに、ここでさらにテストを追加することができます。 app： `Pyramid`を使うテストを書く必要はありません。このファイルは、便宜と例のために提供されています。

app： Pyramid`単体テストの記述については、ref： testing_chapter`を参照してください。

パッケージ構造の変更¶

受け入れられたPyramid cookiecutterのデフォルトからあまり大きく外れないように、アプリケーションのコードレイアウトを調整することをお勧めします。あなたが物事を非常に変えることを控えると、他のピラミッドのコーダーがあなたのアプリケーションをより迅速に理解することができます。ただし、cookiecutterによって作成されたコードレイアウトの選択肢は決して魔法でも必要でもありません。任意のcookiecutterによって選択されたにもかかわらず、コードがどのように見えるか決めることができます。

たとえば、：meth：〜pyramid.config.Configurator.add_view`という名前の設定メソッドは、：term：`点線のPython名 `または直接のオブジェクト参照をビューとして使用するクラスまたは関数として渡す必要があります。デフォルトでは、 ` starter`` cookiecutterはあなたのパッケージ内の `` views.py``モジュールにビュー関数を追加します。しかし、 `` views`` *ディレクトリ*を作成し、それぞれのビューに1つのファイルを追加するほうが快適かもしれません。

もしあなたのプロジェクトパッケージ名が `` myproject``で、あなたのビューを単一の `` views 'の代わりに `` myproject`：term： package`という名前の `views``というPythonサブパッケージに配置したいなら、 .py``ファイルを作成するには、次のようにします。

`` myproject``パッケージディレクトリ（ `` views.py``を保持するのと同じディレクトリ）の中に `` views``ディレクトリを作成します。
`` __init __。py``という名前の新しい `` views``ディレクトリ内にファイルを作成します。（これは空でもかまいません。これは単に `` views``ディレクトリが* package *であることをPythonに伝えます）。
*コンテンツを既存の `` views.py``ファイルから `` blog.py``という名前の新しい `` views``ディレクトリ内のファイルに移動します。 `` templates``ディレクトリは `` myproject``パッケージに残っているので、 `` blog.py``のテンプレート：term： asset specification`の値は、プロジェクトのパッケージ名（ myproject ：templates / blog.pt`）。

ビュー呼び出し可能関数を `` blog.py``モジュールに追加することもできますが、ビュー呼び出し可能関数を含む `` .py``ファイルを `` views``ディレクトリに追加することもできます。 `` @ view_config``ディレクティブを使用して `` config.scan（） ``と一緒にビューを登録する限り、それらはアプリケーションの再起動時に自動的に取得されます。

インタラクティブシェルの使用¶

`` pshell``コマンドを使って、 `` pserve``でPyramidアプリケーションを実行していた場合に読み込まれるのと同じ設定のPythonインタプリタプロンプトを読み込むことができます。これは便利なデバッグツールです。詳細はref： `interactive_shell`を参照してください。

この「pserve」は何ですか？¶

a：app： Pyramid cookiecutterによって生成されたコードは、開発中にアプリケーションを起動するために` pserve``コマンドを使用することを前提としています。 ` pserve``は：term： PasteDeploy` .ini``ファイル（例えば development.ini`）を読み込んで、：app：` Pyramid`アプリケーションを提供するようにサーバを設定するコマンドですファイル内のデータに基づいて

`` pserve``は決して：app： Pyramid`アプリケーションを起動して提供する唯一の方法ではありません。：ref： `firstapp_chapter`で見たように、：app： Pyramid`アプリケーションを実行するために `` pserve``を全く呼び出す必要はありません。 app： Pyramid`アプリケーションを実行するための pserve``の使用は純粋にcookiecutterの出力に基づいて行われます。しかし、他の便利なイントロスペクションコマンド（ ` pviews``、 `` prequest``、 `` proutes`など）の多くは、以下の点で実装されているので、アプリケーションを開発する際に `` pserve``を使うことを強くお勧めします。この `` .ini``ファイル形式の設定可否Pyramidのロギングを設定し、コードが変更されたときにサーバを再起動するための `` --reload``スイッチも提供します。

代替WSGIサーバーの使用¶

Pyramid cookiecuttersは、：term： Waitress WSGIサーバーを使用するプロジェクトを生成します。ウェイトレスは、開発や軽量生産に適したサーバーです。これは、最も高速で機能的なWSGIサーバーでもありません。その代わりに、Pyramidの開発者の視点から、Pyramidを実行する必要があるすべてのプラットフォーム上で動作するため、デフォルトサーバーとして最適です。

どのWSGIサーバーでも、：app： `Pyramid`アプリケーションを実行することができます。しかし、開発のためにデフォルトのサーバーを使用することをお勧めします。アプリケーションを本番環境に展開する準備が整うまで、他のサーバーオプションの調査を待つことをお勧めします。なんらかの理由で非ローカルシステムで開発する必要がある場合を除き、代替サーバーオプションを調べることは通常、展開の準備が整うまでは気をそらすものです。しかし、完全に制御できるローカルシステム上のデフォルト設定を使用して開発することをお勧めします。最高の開発経験を提供します。

デフォルトのWaitressサーバの代用として、term： `mod_wsgi`があります。 mod_wsgi``を使って、Waitressのような"純粋なPython "サーバではなく、Apache Webサーバを使って：app： `Pyramid`アプリケーションを提供することができます。それは速く、特徴的です。詳細はref： `modwsgi_tutorial`を参照してください。

もう一つの優れた生産方法は、用語：「グリーンユニコーン」（別名「ガンコーン」）です。これはWaitressよりも速く、 `` mod_wsgi``より少し構成が簡単ですが、デフォルトの設定では、HTTPプロキシをバッファリングすることに依存しています。この執筆時点では、Windows上では動作しません。

コードの自動リロード¶

開発時には、変更を加えたときにウェブサーバーを自動的に再起動させるのが本当に便利です。 `` pserve``にはこれを有効にする `` --reload``スイッチがあります。これは hupper <https://docs.pylonsproject.org/projects/hupper/en/latest/> `_ packageこの動作を有効にします。コードがクラッシュすると、 ` hupper``は別の変更や `` SIGHUP``シグナルを待ってから再起動します。

inotifyサポート¶

デフォルトで `` hupper``はすべてのPythonコードの変更をファイルシステムにポーリングします。これは、大規模なプロジェクトでは非常に非効率的です。あなたのハードドライブにもっと良くなるためには、 watchdog <http://pythonhosted.org/watchdog/> `開発中のパッケージ。 ` hupper``は自動的に `` watchdog``を使ってより効率的にファイルシステムをポーリングします。

カスタムファイルの監視¶

デフォルトでは、 `` pserve --reload``は全てのインポートされたPythonコード（ `` sys.modules``のすべて）と `` pserve``に渡される設定ファイルを監視します（例えば、 `` development.ini`` ）。あなたの設定ファイルに ` [pserve] ``セクションを定義することによって、 `` pserve``に変更のための他のファイルを見るように指示することができます。たとえば、起動時にアプリケーションが `` favicon.ico``ファイルを読み込んでメモリに格納して、何度も効率的にサービスを提供しているとします。あなたがそれを変更すると、 `` pserve``を再起動します：

[pserve]
watch_files =
    myproject/static/favicon.ico

パスはコンフィグレーションファイルに対して絶対パスでも相対パスでもかまいません。彼らはまた、用語：資産仕様書でもよい。これらのパスは `` hupper``に渡されます。 `` hupper``はglobbingの基本的なサポートをしています。許容されるglobパターンは、使用されているPythonのバージョンに依存します。

(機械翻訳) Pyramid プロジェクトの作成¶

：app： Pyramid cookiecutters¶

プロジェクトの作成¶

新しく開発されたプロジェクトをインストールする¶

アプリケーションのテストの実行¶

プロジェクトアプリケーションの実行¶

コードのリロード¶

アプリケーションの表示¶

プロジェクトの構造¶

`` myproject``：term： Project¶

`` development.ini``¶

production.ini¶

`` MANIFEST.in``¶

`` setup.py``¶

`` myproject``：term： Package¶

`` init 。py``¶

`` views.py``¶

「静的」¶

`` templates / layout.jinja2``¶

`` templates / mytemplate.jinja2``¶

`` tests.py``¶

パッケージ構造の変更¶

インタラクティブシェルの使用¶

この「pserve」は何ですか？¶

代替WSGIサーバーの使用¶

コードの自動リロード¶

inotifyサポート¶

カスタムファイルの監視¶

Table of Contents

前のトピックへ

次のトピックへ

このページ

(機械翻訳) Pyramid プロジェクトの作成¶

：app： Pyramid cookiecutters¶

プロジェクトの作成¶

新しく開発されたプロジェクトをインストールする¶

アプリケーションのテストの実行¶

プロジェクトアプリケーションの実行¶

コードのリロード¶

アプリケーションの表示¶

デバッグツールバー¶

プロジェクトの構造¶

`` myproject``：term： Project¶

`` development.ini``¶

production.ini¶

`` MANIFEST.in``¶

`` setup.py``¶

`` myproject``：term： Package¶

`` __init __。py``¶

`` views.py``¶

「静的」¶

`` templates / layout.jinja2``¶

`` templates / mytemplate.jinja2``¶

`` tests.py``¶

パッケージ構造の変更¶

インタラクティブシェルの使用¶

この「pserve」は何ですか？¶

代替WSGIサーバーの使用¶

コードの自動リロード¶

inotifyサポート¶

カスタムファイルの監視¶

`` init 。py``¶