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. PillowのバイナリをpipでWindowsで扱う話

    まだeasy_installを使っているというかわいそうな人がいるらしいので、 WindowsでもPillowとかのバイナリをpipでインストールできるよという話。 きっとかわいそうな人はPython2.7とかレガシーなの使ってると思うので、 ちゃんと2.7でvirtualenvしたよ！

    PS C:\Users\aodag_2> virtualenv.exe C:\Users\aodag_2\envs\pillow
New python executable in C:\Users\aodag_2\envs\pillow\Scripts\python.exe
Installing setuptools, pip...done.
PS C:\Users\aodag_2> .\envs\pillow\Scripts\activate.ps1
(pillow) PS C:\Users\aodag_2> pip --version
pip ...
    read more

    There are comments.

  5. 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.

  6. 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.

Page 1 / 1

blogroll

social