Other articles

  1. pipとwheelでテスト環境構築をスピードアップ

    まず最初にお知らせ。 travisでtoxをつかうtips で、travisにpython3.4をインストールして、toxの環境振り分けをするってのを書きましたが、すでにtravisでpython3.4使えるようなので、事前のapt-getは不要となりました。

    そして、 ubuntus 14.04 trusty では python3.4がデフォルトでインストールされているようですが、 ensure-pip が入っていないという罠により pyvenv するとエラーになります。 とりあえず debian系の python パッケージは変なパッチあたってるのも、そろそろいい加減にしてほしいところなので、もうしばらくはpython3.4はソースインストールでやっていくことにします。

    ここから本題。 travis や drone.io などでciを動かしている場合、テストごとに環境を作成しているわけですが、依存ライブラリが増えてくるとこの部分で結構な時間がとられます。 下手するとテストよりも環境構築に時間がかかるわけで、時間の限られた条件の中で利用する貧乏人としては、本質的じゃないところのコストはできるだけ減らしたいもの。 ということでいろいろ試行錯誤の末、以下のようにしました。

    • 依存ライブラリはリポジトリに入れる
    • toxなどでリポジトリ内の依存ライブラリを参照するように調整する
    • toxにテストの詳細を記述し、travis.yml にはtox実行に必要なものだけ書く

    ３つ目はすでに travisでtoxをつかうtips にも書いたことなので細かい説明はしません ...

    read more

    There are comments.

  2. travisでtoxをつかうtips

    さて、python3.4とか trove にも登録されたし、自分で書いてるライブラリは対応させてこうかなというところです。

    で、各種バージョンでのテストを通すのに tox 使うのが最近の常識になってきていると思いますが、travisでciをしようとすると、.travis.ymlに同じようなことを書いてしまうわけです。 さらに、今のところ travis ではpython3.4が入っていない。

    最近注目している次期PyPIの実装である warehouse をみていたら、python3.4でtravisでのテストを実行させている。 しかも、中でtoxを呼ぶようにしている。

    python3.4は単にdeadsnakesからapt-getでインストールしているだけです。 tox呼ぶこと自体は簡単で、単に .travis.yml で script に tox を指定すればOK。 ただし、これだと tox ですべてのバージョンを一気にテストするわけで、どこかのバージョンでテストが失敗したのかわからなくなります。 あとなんかせっかくtravisでヴァージョンごととかできるのに、そうならなくなってるのが非常にださい。

    warehouseの .travis.yml では、環境変数 TOXENV のmatrixを設定してありました ...

    read more

    There are comments.

  3. ubuntuでpyvenvしたときの落とし穴

    dockerでアプリケーションテスト用の環境を作ろうとしたときにはまったので、誰得メモ。

    python3.3のwebアプリケーションのテストをpostgresqlとかredisとかを簡単にリセットできる環境がほしいと思ったので、dockerで試していました。 で、なんかsaucyのイメージって公式っぽい base リポジトリにはなかったので、とりあえずppa:deadsnakesで各種バージョンのPythonが完備されているshimizukawa/python-allを使ってみました。

    そして、dockerの中で環境作るためにpyvenvしてからのget-pip.pyをしたところ、pipが $VIRTUAL_ENV/bin じゃなくて、 $VIRTUAL_ENV/local/bin にインストールされてしまう問題に気づきました。 これだとPATHに含まれてないので、最初はpipのインストールに失敗したように見えます。 実際は違うところにインストールされていました。

    で、なぜだろうと原因を探りつつ、発生する条件を特定してみると

    • activateした場合は発生しない。pyvenvしたpythonをパス指定で実行すると発生する。
    • ソースインストールしたPythonでは発生しない。
    • deadsnakesでなくともubuntuのパッケージで入れたPython3.3でも発生する。
    • pyvenvじゃなくて、virtualenvのときは発生しない。

    まずactivateすると発生するってことで、その前後でsite-packagesを調べると、activateするとpyvenvした環境がsite.getsitepackages()の結果に含まれていることがわかりました。 pipは最終的に、 setup.py install を呼ぶようになってるので、このあたりの情報が狂ってしまうとどうしようもないのでしょう。 ソースインストールしたPythonではそういった動作はしてなかったので、パッケージの場合に当てられてるパッチかなと思い、パッケージソースを確認してみます ...

    read more

    There are comments.

  4. Pyramidのセキュリティ

    始めに断っておこう。Pyramidにはファンシーなログインフォームやユーザー管理なんてついてこない。 認証、認可の仕組みはあるが、Pyramidに設定一発で動くような押しつけがましいViewやModelは存在しない。 そういうのが好きな人はDjangoというフレームワークがあるから、そっちにしときな。

    このエントリでは、Pyramidで認証、認可の仕組みを使う方法を説明する。 CSRFとかそういうのは扱わないのであしからず。

    Pyramidのセキュリティの仕組み

    先に述べたとおりPyramidには認証と認可の仕組みがある。 認証というのは、今アプリケーションを使っているのが誰なのかを特定するもので、 認可は誰がその機能や処理を実行してよいかということである。

    認証

    Pyramidの認証では、AuthenticationPolicyがリクエストからprincipalを取り出すという方法で実現している。 princpalというのはユーザーがシステムの中でどのように認識されているかということであり、 例えば単純にログインユーザーで判定されることもあるし、特定のIPアドレスやネットワークからアクセスしているといった情報から判定されることもある。

    Pyramidで標準で用意されているAuthenticationPolicyでわかりやすいのはBasicAuthAuthenticationPolicyだろう。 このポリシーが設定されていると、リクエストのAuthorizationヘッダの情報からprincipalを生成する。 このほかに、セッションやクッキーなどで認証情報を保持するポリシーが用意されている。

    結局のところ用意されているのは、リクエストからprincipalを取り出す方法だけで、実際にそのprincipalを有効なものだと判定するのは、アプリケーション側にゆだねられている。 有効なprincipalと判定した後に、rememberメソッドによってAuthenticationPolicyに渡すと、それ以降のPyramidのセキュリティメカニズムの中で利用されるというわけだ。

    認可

    さて、利用者の役割などがわかれば、次はその人に何が許されているかという話になる。 Pyramidでは、許されていること(権限 ...

    read more

    There are comments.

  5. Pyramidのコントローラースタイル

    とりあえずコントローラースタイルと書いたが、ようするにWebアプリケーションがリクエストを受け取ってから処理に入るまでの流れである。 Pyramidはあえて複数の方法を採用している。その他のフレームワークから来る人たちがお気に入りの方法をとれるようにするためだ。 大きく分けて、Zope系由来のトラバーサル、DjangoやPylonsが使っているURLディスパッチがある。 (TurboGearsはPylons上のフレームワークだけどURLディスパッチをオミットしてトラバーサルっぽい動きをする) Pyramidはこの2種類をそれぞれ使えるし、同時に利用することもできる。 とりあえず2種類を説明して、そのあとに混合したパターンを説明しよう。

    URLディスパッチ

    最近のWebフレームワークはこちらが主流になっているようだ。 URLを正規表現やそれに近いパターンで解析して、パターンごとのコントローラーやビューを呼び出す。 リクエストからレスポンスまでの処理のは以下のようになる。

    • URLパターンマッチング
    • パターンに対応するビューの呼び出し
    • ビューの中でモデルをローディング
    • ビューがテンプレートにモデルを渡す

    PyramidでのURLディスパッチ

    Pyramidはルーティングとビューの登録がわかれている。

    ルーティング:

    config.add_route("user", "/users/{user_id}")

    "user"ルートのURLパターンの登録である。 "{}" で囲まれている部分はプレースホルダーとなっていて、この部分に相当するパラメータは ...

    read more

    There are comments.

  6. pipのsetuptools離れ

    年明けに pip 1.5 がリリースされ、1.4でのpreリリースの扱いに加えて、外部サイトにおいてあるライブラリがインストールできなくなった(allow-externalオプションが必要)り、httpsじゃないサイトからのダウンロードができなくなった(allow-unverified )り、阿鼻叫喚のようです。

    そのあたりはエラーメッセージの通りにしてよね！ってことで、そことは別の話です。

    pip1.5以降はpkg_resourcesというsetuptoolsに入ってたモジュールをpip内に同梱するようになりました。 1.4のときにdistlibも同梱されるようになっているため、pythonのパッケージングに関するユーティリティライブラリを新旧ともにpipは同梱するようになったわけです。

    さらに get-pip はsetuptoolsがなければそれもインストールするようになりました。 って話で終わると、別にsetuptools離れしてないじゃんということになりますが。 get-pipの動作を見ていると、pipをインストールしてから、setuptoolsをインストールしています。 ここで、1.5以降のChangeLogを見てみると、pipはsdistをインストールするとき以外はsetuptoolsを必要としなくなったと書いてあります。 get-pipはpipとsetuptoolsをwheel形式を使ってインストールするので、pipがsetuptoolsをインストールするということが可能になったわけです。 で、pyvenv/ensure-pipやvirtualenvなどは環境作成時にpipもsetuptoolsもインストールするので、setuptoolsなしでpipのみという環境はそうそう存在しないのです。 とはいえ、できるようになったというのなら確認してやろうじゃありませんか。

    今のところの最新安定版のpython3.3に入っているpyvenvはensure-pipがないので、まっさらな環境を作成できます。この環境にpipのみの単独インストールをしてみます。

    さて、pipをインストールするといってもpipのsetup.pyはsetuptoolsを使っているので、wheelからのインストールを検討しなければなりません ...

    read more

    There are comments.

  7. New Year's Python Meme 2014

    Last Year

    What’s the coolest Python application, framework or library you discovered this year?

    • ansible
    • testfixtures
    • Kaa

    What new programming technique did you learn this year?

    • Using adapter to split feature and domain
    • Repository Pattern

    Which open source project did you contribute to the most this year? What did ...

    read more

    There are comments.

  8. 効果的なunittest - または、callFUTの秘密

    https://twitter.com/tokibito/status/412074246026698753

    ということで _callFUT とはなんぞって話。 簡単に言えば、 Pylons Project の Unit Testing Guidelines で使われてる用語なんだけど、 FUT = Function Under the Test の略 ...

    read more

    There are comments.

  9. Python Advent Calendar 2013 10日目 僕が知っているみんなが知ってるはずのこと

    Python Advent Calendar 2013 の10日目だ。

    今年はWebじゃない縛りってことで、生粋のWebプログラマーの僕としては結構苦労するテーマである。 (Webじゃない縛りを提案したのは僕ってことはさておきだね)

    で、いろいろ考えたけど結構むずかしい。 py.testとnoseがどっちがいいかなんて3年以上前の話題だし、 pyqtやらnumpyとかopencvもARの集落を見ると解説するのも億劫だ。

    で。ちょっと思いついたのは、pycon apac前後で質問されたこの内容だ。

    「どこからそういう情報を得るのですか？」

    僕にとっては非常に衝撃的な質問だった。 なぜなら僕が知ってることはみんなが知っていても不思議じゃない。 僕は開発者とのつながりってそれほどないし、公開情報をおっかけてるだけなんだ。 どこからと言われても、それは購読しているMLを教えればいいのだろうか？ だって、そのMLの参加資格はなにもないし、そんなにマイナーなMLじゃない。 だって、python.org直下のSIGのMLなんだよ？ Distutil Sig

    ということで Python Apacで発表したときの元ネタは、 Distutils-SIG ってところだ。 うん。このMLを読めば僕と同じ情報を手にしているはずだ。 たんに継続しただけってことかもしれないし、そこまでの情熱はないけど最新情報を誰かがまとめてくれているってだけで十分かもしれない。

    僕も現にそう思っていたし、身近な人間（まあ名前は伏せておくとして、本人が嫌がるので心の中でだけ唯一「先生」と僕がつける存在だ）がそういう情報をみていなければ、 僕だって同じように、まとまった情報を受け入れる立場だったに違いない ...

    read more

    There are comments.

Page 1 / 2 »

blogroll

social