Pythonを取り巻く開発環境 #pyconjp
- 1. Pythonを取り巻く開発環境 id : ymotongpoo 1"
- 2. 今日の資料 • 細かい説明はブログに書いた – http://ymotongpoo.hatenablog.com/entry/ 2012/09/16/090842 • スライドも載せた – https://docs.google.com/open? id=0B5k3Cg7nkTt1UnRVbTNhYl9PNjA
- 3. なのでスライドと僕を見て 話を聴いて どんどん質問して下さい
- 4. Agenda • 自己紹介 • 今日の概要 • ローカル開発環境 – コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト • 統合環境 – 継続テスト – ドキュメント
- 5. お前、だれよ？ • id: ymotongpoo（とんぷー） – YAMAGUCHI::weblog http://ymotongoo.hatenablog.com • YouTube • 翻訳 – Jinja2 – Tornado
- 6. Agenda • 自己紹介 • 今日の概要 • ローカル開発環境 – コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト • 統合環境 – 継続テスト – ドキュメント
- 7. 概要 • 話すこと – Pythonで開発を行う際の土台作り – Python初心者向け • もう環境構築のことで悩まない – 他言語経験者向け • Pythonの文法がひと通りわかったらこれ を読んで下さい
- 8. 概要 • 話さないこと – コーディング規約 – レビュー制度 – Web開発のベストプラクティス • 今日は部品についてのお話
- 9. Agenda • 自己紹介 • 今日の概要 • ローカル開発環境 – コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト • 統合環境 – 継続テスト – ドキュメント
- 10. ローカル開発環境 • コード編集 • Pythonの管理 • パッケージ管理 • ワークスペース • テスト
- 11. コード編集 好きなモノを使え！！！ • Emacs • Vim • Sublime Text 2 • PyCharm • Eclipse
- 12. ローカル開発環境 • コード編集 • Pythonの管理 • パッケージ管理 • ワークスペース • テスト
- 13. Pythonの管理 • 複数バージョンのPythonを管理する Python 2.7 メインで使うPython Operation System Python 2.6 Python 3.1 検証等で使うPython Python 3.2 Python 3.3
- 14. Pythonの管理 • 複数バージョンを統一して管理する 方法を考える Linux/Unixの例 Windowsの例
- 15. Pythonの管理 • Windows インストール先指定可 バイナリ MSIパッケージ VC++
- 16. Pythonの管理 • Linux インストール先指定可 バイナリ apt-get, yum make
- 17. Pythonの管理 • Mac OS X インストール先指定可 バイナリ homebrew homebrew MacPorts MacPorts dmg make
- 18. ローカル開発環境 • コード編集 • Pythonの管理 • パッケージ管理 • ワークスペース • テスト
- 19. パッケージ管理 • 実用上パッケージ管理は不可欠 様々な場所からパッ ケージをインストール PyPI Python 2.7 Operation System VCS site'packages" bucho aodag Python 2.6 lxml tarball, zip nose Python 3.1 Python 3.2 Python 3.3
- 20. パッケージ管理 • setup.py – distutils, setuptools, distribute • easy_install – setuptools, distribute • pip • pysetup – distutils2
- 21. パッケージ管理 • 関連パッケージの歴史的経緯 昔 setup.pyを書くためのモジュール →いちいちzipから入れるのめんどい →easy_install（& cheeseshop） distutils setuptools distribute easy_installの壁 Python 3の壁 拡張メタデータの壁
- 22. パッケージ管理 • 関連パッケージの歴史的経緯 現在∼将来 Python 2.x Python 3.x 未だにまともに Python3で動 かない pip pip 利用 利用 Python3.3で標準 終了 easy_install easy_install に取り込みに失敗 setuptools distribute distribute distutils2 distutils distutils packaging
- 23. パッケージ管理 • setup.py – 配布するPythonパッケージを作成する 際にはかならず必要 – 最終的にはこれだけで必要なことが出 来るべき • testを走らせる • C/API拡張のビルド
- 24. パッケージ管理 • easy_install – setuptoolsより利用可能になったパッ ケージインストーラ – distributeのものを利用すること
- 25. パッケージ管理 • ''upgrade,"'U":" " • ''always'unzip,"'Z":"zip " • ''mul:'version,"'m":" "or" "
- 26. パッケージ管理 • pip – リリース当時はeasy_installよりもイケ メンだった – 今も便利です
- 27. パッケージ管理 • install":" " • ''upgrade,"'U":" " • uninstall":" " • freeze":" " • bundle":" zip "
- 28. パッケージ管理 • pysetup（参考） – distutils2同梱のコマンド – Python3.3でpackagingが標準で入 るときに取り込まれる予定だった
- 29. ローカル開発環境 • コード編集 • Pythonの管理 • パッケージ管理 • ワークスペース • テスト
- 30. ワークスペース • 開発環境毎にパッケージを分離 システム直のPythonで開発すると Python 2.7 プロジェクトA プロジェクトB Operation System • bucho 1.0 • bucho 2.0 site'packages" • aodag 1.1 • aodag 1.2 … … Python 2.6 に依存 に依存 Python 3.1 Python 3.2 パッケージのバージョンで不都合 Python 3.3
- 31. ワークスペース • プロジェクト毎に分けよう プロジェクトA Python 2.7 Python 2.7 • Pythonバイナリ • site-packages Operation System bucho 1.0 Python 2.6 aodag 1.1 を持った環境を別 途作成することで、 Python 3.1 プロジェクトB 分離が可能になる。 Python 2.7 Python 3.2 bucho 2.0 aodag 1.2 Python 3.3
- 32. ワークスペース • virtualenv (virtualenvwrapper) • zc.buildout • venv （Python 3.3から）
- 33. ワークスペース • virtualenv – 仮想環境作る専用のツール – 使いやすい
- 35. ワークスペースの管理 • zc.buildout – ビルドツールなので汎用性高い – システムのsite-pakagesを引きずる – レシピ見つけるのが大変 – buildout.cfg書くの慣れるまで大変
- 36. ワークスペースの管理 • zc.buildout 1. 初期化 2. buildout.cfg 3. 環境作成
- 37. ワークスペースの管理 • venv – Python 3.3から標準で入った – パッケージ管理が標準だとしょぼいの で片手落ち
- 38. ローカル開発環境 • コード編集 • Pythonの管理 • パッケージ管理 • ワークスペース • テスト
- 39. テスト • テストはなるべく自動化したい プロジェクトA Python 2.7 Python 2.7 Test Suite Operation System bucho 1.0 Python 2.6 aodag 1.1 Python 3.1 Python 3.2 ①テストスイートを書く仕組み ②テストを実行する仕組み の両方が必要 Python 3.3
- 40. テスト • unittest, doctest • nose, py.test
- 41. テスト • unittest, doctest – 標準で入っている – setup.pyにはこれしか含まないべき
- 42. テスト • nose, py.test – どっちも超メジャー – noseはプラグイン書ける • 逆にいうとプラグイン無いと困る – pytestは後発なので単体で便利 • でもプラグイン書けない – どっちを使うかは好み
- 43. テスト • 複数のバージョンのテスト プロジェクトA Python 2.7 Python 2.7 Test Suite Operation System bucho 1.0 Python 2.6 aodag 1.1 Python 3.1 Python 2.6 bucho 1.0 Python 3.2 aodag 1.1 同じテストを自動 で複数の環境で走 Python 3.3 らせたい プロジェクトA
- 45. テスト • tox – 各テスト環境のvirtualenvを自動作成 ＆自動テスト実行 – py.testと同じプロジェクトチームなの で相性が良い
- 46. テスト • tox 1. tox.ini書く 2. toxコマンド
- 47. Agenda • 自己紹介 • 今日の概要 • ローカル開発環境 – コード編集 – Pythonの管理 – パッケージ管理 – ワークスペース – テスト • 統合環境 – 継続テスト – ドキュメント
- 49. 継続テスト • VCSと連携した自動ビルドシステム VCS bucho 1.0 xUnit.xml aodag 1.1 プロジェクトA Test Suite Python 2.7 Python 2.7 Operation System bucho 1.0 Test Suite Python 2.6 aodag 1.1 Python 3.1 Python 3.2 ポーリングやフックで テストを実施する Python 3.3
- 50. 継続テスト • Jenkins (+plugin) – BuildHive • Travis CI
- 51. 継続テスト • Jenkins – 言わずと知れた継続インテグレーション システム – Pluginを入れることでPythonのテス トランナーを走らせることが可能 • Shining Panda Plugin • Python Plugin
- 52. 継続テスト • Travis CI – GitHub内のレポジトリをWebフック でビルドするホスティングサービス – 個人プロジェクト、OSSではメンテコ ストが格段に下がる
- 53. 継続テスト • Travis CI – .travis.yaml
- 55. ドキュメント • 製品と連携したアップデートが必要 • Sphinxを利用 • 継続的にリリースするためにCI環境 を使用 – Jenkins – Read The Docs
- 56. ドキュメント • Sphinx – 複数のreSTから相互参照含めた複雑な ドキュメントを生成可能 – 複数の形式を生成（HTML, ePub, PDF）
- 57. ドキュメント • Jenkinsを用いる場合 – ビルド成功時にドキュメントをデプロイ する仕組みを作る – 最悪ワークスペースを公開
- 58. ドキュメント • Read The Docs – Django製のSphinxドキュメント専用 継続インテグレーションシステムおよび ホスティングサービス – Git, Mercurial, Subversionのレポジ トリとWebフックで連携
- 60. 構成案1 • 個人プロジェクト Travis CI Read The Docs make virtualenv Python 2.7 Python 2.7 py.test Python 2.6 easy_install Mac or Linux tox Python 3.1 Python 3.2 Python 3.3
- 61. 構成案2 • プロプライエタリ製品 Jenkins make virtualenv Python 2.7 Python 2.7 nose Python 2.6 easy_install Mac or Linux tox Python 3.1 Python 3.2 Python 3.3
- 62. 構成案3 • 某BP社 make virtualenv Python 2.7 Python 2.7 nose pip Mac