Pythonを取り巻く開発環境

id : ymotongpoo

1"

今日の資料

• 細かい説明はブログに書いた –  http://ymotongpoo.hatenablog.com/entry/2012/09/16/090842

• スライドも載せた –  https://docs.google.com/open?id=0B5k3Cg7nkTt1UnRVbTNhYl9PNjA

��

��

なのでスライドと僕を見て 話を聴いて

どんどん質問して下さい

Agenda

•  自己紹介 •  今日の概要 •  ローカル開発環境

– コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト

•  統合環境 – 継続テスト – ドキュメント

��

お前、だれよ？ •  id: ymotongpoo（とんぷー）

– YAMAGUCHI::weblog http://ymotongoo.hatenablog.com

•  YouTube • 翻訳

– Jinja2 – Tornado

��

Agenda

•  自己紹介 •  今日の概要 •  ローカル開発環境

– コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト

•  統合環境 – 継続テスト – ドキュメント

��

概要

• 話すこと – Pythonで開発を行う際の土台作り – Python初心者向け

• もう環境構築のことで悩まない – 他言語経験者向け

• Pythonの文法がひと通りわかったらこれを読んで下さい

��

概要

• 話さないこと – コーディング規約 – レビュー制度 – Web開発のベストプラクティス

• 今日は部品についてのお話

��

Agenda

•  自己紹介 •  今日の概要 •  ローカル開発環境

– コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト

•  統合環境 – 継続テスト – ドキュメント

��

ローカル開発環境

• コード編集 •  Pythonの管理 • パッケージ管理 • ワークスペース • テスト

���

コード編集

•  Emacs •  Vim •  Sublime Text 2 •  PyCharm •  Eclipse

���

好きなモノを使え！！！

ローカル開発環境

• コード編集 •  Pythonの管理 • パッケージ管理 • ワークスペース • テスト

���

Pythonの管理

• 複数バージョンのPythonを管理する

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Operation Sy

stem

メインで使うPython

検証等で使うPython

Pythonの管理

• 複数バージョンを統一して管理する方法を考える

���

4595>9-43�ECC����ECC����ECC� ��DCC� ��

Linux/Unixの例 ��#�>9-43#�ECC����ECC����ECC� ��DCC� ��

Windowsの例

Pythonの管理

• Windows

���

インストール先指定可 バイナリ

MSIパッケージ

VC++

Pythonの管理

•  Linux

���

インストール先指定可 バイナリ

apt-get, yum

make

Pythonの管理

• Mac OS X

���

インストール先指定可 バイナリ

homebrew MacPorts

dmg

make

homebrew MacPorts

ローカル開発環境

• コード編集 •  Pythonの管理 • パッケージ管理 • ワークスペース • テスト

���

パッケージ管理

• 実用上パッケージ管理は不可欠

���

Python 2.7

Python 3.3

Operation Sy

stem

Python 3.2 Python 3.1 Python 2.6

site'packages" bucho aodag lxml nose

PyPI

VCS

tarball, zip

様々な場所からパッケージをインストール

パッケージ管理

•  setup.py – distutils, setuptools, distribute

•  easy_install – setuptools, distribute

•  pip •  pysetup

– distutils2 ���

パッケージ管理

• 関連パッケージの歴史的経緯

���

distutils setuptools distribute

昔

easy_installの壁 拡張メタデータの壁

Python 3の壁

setup.pyを書くためのモジュール →いちいちzipから入れるのめんどい →easy_install（& cheeseshop）

パッケージ管理

• 関連パッケージの歴史的経緯

���

distutils

現在～将来 Python 2.x Python 3.x

distribute distribute

distutils

easy_install easy_install

pip pip

setuptools

終了 distutils2

packaging

利用 利用

未だにまともにPython3で動かない

Python3.3で標準に取り込みに失敗

パッケージ管理

•  setup.py – 配布するPythonパッケージを作成する際にはかならず必要

– 最終的にはこれだけで必要なことが出来るべき •  testを走らせる • C/API拡張のビルド

���

パッケージ管理

•  easy_install – setuptoolsより利用可能になったパッケージインストーラ

– distributeのものを利用すること

���

パッケージ管理

���

��*&8>%.389&11�B !�':(-4����*&8>%.389&11�B2�':(-4�

•  ''upgrade,"'U":"���� .5)14%+0'35-"•  ''always'unzip,"'Z":"zip ����&4*,52"•  ''mul:'version,"'m":" .5)14�&4*,52"or"��"

パッケージ管理

•  pip – リリース当時はeasy_installよりもイケメンだった

– 今も便利です

���

パッケージ管理

���

��5.5�.389&11�B �':(-4���5.5�:3.389&11�':(-4���5.5�+7**?*���7*6:.7*2*3989=9���5.5�':3)1*� ����%����5>':3)1*��������%������

•  install":"&4*,52"•  ''upgrade,"'U":"���� .5)14%+0'35-"

•  uninstall":"��"•  freeze":"�!&4*,52�#�"/+(5)��$��"•  bundle":"�!&4*,52�#�"/+(5)$zip�"

パッケージ管理

•  pysetup（参考） – distutils2同梱のコマンド – Python3.3でpackagingが標準で入るときに取り込まれる予定だった

���

ローカル開発環境

• コード編集 •  Pythonの管理 • パッケージ管理 • ワークスペース • テスト

���

ワークスペース

• 開発環境毎にパッケージを分離

���

Python 2.7

Python 3.3

Operation Sy

stem

Python 3.2 Python 3.1 Python 2.6

site'packages"

システム直のPythonで開発すると プロジェクトA •  bucho 1.0 •  aodag 1.1 … に依存

プロジェクトB •  bucho 2.0 •  aodag 1.2 … に依存

パッケージのバージョンで不都合

ワークスペース

• プロジェクト毎に分けよう

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Operation Sy

stem

Python 2.7 bucho 1.0 aodag 1.1

Python 2.7 bucho 2.0 aodag 1.2

プロジェクトA

プロジェクトB

•  Pythonバイナリ •  site-packages を持った環境を別途作成することで、分離が可能になる。

ワークスペース

•  virtualenv (virtualenvwrapper) •  zc.buildout •  venv （Python 3.3から）

���

ワークスペース

•  virtualenv – 仮想環境作る専用のツール – 使いやすい

���

��;.79:&1*3;���).897.':9*�85&2���84:7(*�85&2'.3&(9.;&9*��85&2����*&8>%.389&11�� !�':(-4��85&2����)*&(9.;&9*��

ワークスペース

•  virtualenvwrapper – virtualenvがより使いやすくなる

���

��20;.79:&1*3;�85&2��85&2����*&8>%.389&11�B !�':(-4��85&2����<47043�*,,��*,,�����

ワークスペースの管理

•  zc.buildout – ビルドツールなので汎用性高い – システムのsite-pakagesを引きずる – レシピ見つけるのが大変 – buildout.cfg書くの慣れるまで大変

���

ワークスペースの管理

•  zc.buildout 1. 初期化 2. buildout.cfg 3. 環境作成

���

��':.1)4:9�.3.9�

"':.1)4:9$�5&798�����)*;��")*;$�7*(.5*���?(7*(.5**,,�*,,8�����85-.3=���85-.3=(4397.'�'14(0).&,���85-.3=(4397.'�3*9<470).&,�������.39*757*9*7���5>�

��'.3':.1)4:9�

ワークスペースの管理

•  venv – Python 3.3から標準で入った – パッケージ管理が標準だとしょぼいので片手落ち

���

ローカル開発環境

• コード編集 •  Pythonの管理 • パッケージ管理 • ワークスペース • テスト

���

テスト

• テストはなるべく自動化したい

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Operation Sy

stem

Python 2.7 bucho 1.0 aodag 1.1

プロジェクトA

Test Suite

①テストスイートを書く仕組み ②テストを実行する仕組み の両方が必要

テスト

•  unittest, doctest •  nose, py.test

���

テスト

•  unittest, doctest – 標準で入っている – setup.pyにはこれしか含まないべき

���

テスト

•  nose, py.test – どっちも超メジャー – noseはプラグイン書ける

• 逆にいうとプラグイン無いと困る – pytestは後発なので単体で便利

• でもプラグイン書けない – どっちを使うかは好み

���

テスト

• 複数のバージョンのテスト

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Operation Sy

stem

Python 2.7 bucho 1.0 aodag 1.1

プロジェクトA

Test Suite

Python 2.6 bucho 1.0 aodag 1.1

プロジェクトA’

同じテストを自動で複数の環境で走らせたい

テスト

•  tox •  zc.buildout

���

テスト

•  tox – 各テスト環境のvirtualenvを自動作成＆自動テスト実行

– py.testと同じプロジェクトチームなので相性が良い

���

テスト

•  tox 1.  tox.ini書く 2.  toxコマンド

���

"94=$�*3;1.89���5>����5> ���"9*89*3;$�)*58�����5>9*89���7*6:*898��(422&3)8�����5>9*89�#�������/:3.9=21�/:3.9�@*3;3&2*A=21�#�����9*89�

��94=�

Agenda

•  自己紹介 •  今日の概要 •  ローカル開発環境

– コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト

•  統合環境 – 継続テスト – ドキュメント

���

統合環境

• 継続テスト • ドキュメント

���

継続テスト

•  VCSと連携した自動ビルドシステム

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Operation Sy

stem

Python 2.7 bucho 1.0 aodag 1.1

プロジェクトA

VCS

Test Suite

Test Suite

bucho 1.0 aodag 1.1

xUnit.xml

ポーリングやフックでテストを実施する

継続テスト

•  Jenkins (+plugin) – BuildHive

•  Travis CI

���

継続テスト

•  Jenkins – 言わずと知れた継続インテグレーションシステム

– Pluginを入れることでPythonのテストランナーを走らせることが可能 • Shining Panda Plugin • Python Plugin

���

継続テスト

•  Travis CI – GitHub内のレポジトリをWebフックでビルドするホスティングサービス

– 個人プロジェクト、OSSではメンテコストが格段に下がる

���

継続テスト

•  Travis CI – .travis.yaml

���

1&3,:&,*��5>9-43�5>9-43������������������������� �������� ���.389&11�������5.5�.389&11��7�7*6:.7*2*3989=9�8(7.59������5>9*89�9*89�

統合環境

• 継続テスト • ドキュメント

���

ドキュメント

• 製品と連携したアップデートが必要 •  Sphinxを利用 • 継続的にリリースするためにCI環境を使用 – Jenkins – Read The Docs

���

ドキュメント

•  Sphinx – 複数のreSTから相互参照含めた複雑なドキュメントを生成可能

– 複数の形式を生成（HTML, ePub, PDF）

���

ドキュメント

•  Jenkinsを用いる場合 – ビルド成功時にドキュメントをデプロイする仕組みを作る

– 最悪ワークスペースを公開

���

ドキュメント

•  Read The Docs – Django製のSphinxドキュメント専用継続インテグレーションシステムおよびホスティングサービス

– Git, Mercurial, SubversionのレポジトリとWebフックで連携

���

���

話も飽きたと思うので 実例を考えてみます

構成案1

• 個人プロジェクト

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Mac

or L

inux

Python 2.7 py.test

virtualenv

easy_install

make

tox

Travis CI

Read The Docs

構成案2

• プロプライエタリ製品

���

Python 2.6

Python 2.7

Python 3.1

Python 3.2

Python 3.3

Mac

or L

inux

Python 2.7 nose

virtualenv

easy_install

make

tox

Jenkins

構成案3

• 某BP社

���

Python 2.7

Mac

Python 2.7 nose

virtualenv

pip

make