matcha0.1リリースのお知らせとその背景
matcha という WSGI dispatcher をリリースしました｡ WSGIのライブラリ/ミドルウェアで､PATH_INFOを考慮した WSGIアプリケーションの呼び出しを主目的にしています｡
この記事では matcha の紹介を軽くしつつ､ 後半では本音として書きたかった dispatcher を実装して思ったことを書きます｡
matchaの利点
matcha が売りにできるのは Djangoのurls.pyっぽく書ける の､1点ですね｡ 基本的にはこんなかんじで記述します:
>>> from matcha import Matching as m, bundle
>>>
>>> from yourproject import home_app
>>> from yourproject.blog import post_list_app, post_detail_app
>>>
>>> matching = bundle(
... m('/', home_app, 'home'),
... m('/post/', post_list_app, 'post_list'),
... m('/post/{post_slug}/', post_detail_app, 'post_detail'),
... )
bundleとかMatchingとかちょっと名前が違うくらいですね｡
他にも matcha は以下の点において便利です:
- 上記のように宣言的に書けるし､手続き的にも書ける
- 名前(上記の例だと’post_listなど’)からURLの逆引きができる
- WSGIアプリケーションの呼び出し意外にも使える
機能的に matcha は他のdispatcherと大して変わらないです｡ 他にもいくつか dispatcher ありますが､ matcha を除いた中では WebDispatchが良さげです:
dispatcherを4つくらい作って思った
公開したもの2つ､公開してないもので2､3 dispatcher を書いてみた印象としては URL での dispatch は分割して用意したほうが良い ということです｡
URL での dispatch にはある程度持っておきたい機能があります:
- environのPATH_INFO, SCRIPT_NAMEに副作用を起こす
- URLからの引数取得
- 名前/対象アプリケーションから URL の逆引き
これらの機能を実現しつつ､「URL にとらわれない柔軟な dispatcher」を作るのは 難しかったです(詳細は後述)｡
matcha では(少なくとも 0.1 リリースでは) URL からのマッチングのみ 提供し､それ意外の条件での dispatch は利用者や matcha を使ったWebフレームワーク の開発者に提供してもらうことにします｡
route_nameを噛ませればPyramidのように使えますし､URLでのdispatchしか提供しないので あればDjangoのようになります｡
matchaと私とときどきgargant.dispatch
つい1ヶ月ほど前に gargant.dispach を リリースし､ PyCon APAC 2013 のLTでも紹介したばかり ですが､ matcha を書き始めました｡その経緯など｡
gargant.dispatch はかなり優秀で実装も面白いのですが､柔軟にしすぎようとしたせいもあり 以下の点で URL dispatcher として劣っていました｡:
- PATH_INFO, SCRIPT_NAMEに副作用を起こさない
- 名前/対象アプリケーションから URL の逆引きができない
- URLから引数を取るのが面倒
先ほども少し触れたところです｡
これは gargant.dispatch が「matchingというものを PATH_INFO や REQUEST_METHODのみを 対象にしない」という考えのもとに作られているので「URLの逆引き」のような PATH_INFO に必ず 依存する実装が持たせにくいというものでした｡
もちろんやりようによってはできると思いますが､柔軟性を維持しつつ そういった制約(WSGIの仕様やWebアプリケーションでよく使われる機能)への対応 を入れるのは意外と難しかった(だるかった)です｡
まぁ gargant.dispatch もかなり良い勉強になったのでこのまま廃れてもまぁいいかなという思いです｡ パッケージにおける gargant 以下は実験的なWebフレームワークを作るための場所としていますし｡ ただ実験的なものだけじゃなくて､実用的なものもちゃんと作っておきたいところなので､ matcha は集大成でもありますね｡
テンプレートエンジンでも作るか
と思っています｡ そもそも私は別に「dispatcherを書きたいオジサン」というわけでなく､ Webアプリケーションにおいてサーバーサイドで必要なものを下から見た場合に dispatcherがあったということです｡すでにWebサーバーは書き散らして飽きて､ Request/Responseオブジェクトはだるかったので飽きてます｡
なので次はテンプレートエンジンでも作ってみようかなと思っています｡
Mac & Mercurialユーザーにオススメ､TortoiseHgのナイトリービルド版があるよ
熱心なMercurialユーザーに支持を集めるTortoiseHgですが､ そのTortoiseHgのMac向けのビルド版がダウンロードできるようです｡
ここでは簡単な紹介と､Non-ASCII件で起こる問題の解決方法を書きます｡
TortoiseHgとは
MercurialのGUIクライアントです｡ Git難しいDVCS難しいという方にこそオススメしたいMercurialですが､ そのGUIクライアントのなかでも優秀と評判なのがTortoiseHgです｡
私個人的に､SourceTreeなどと比べて､TortoiseHgが素晴らしいのは Mercurial Queue(MQ)対応です｡Mercurialの拡張機能への対応も充実しているのは とてもありがたいです｡というのも私は普段MQも使っているので､MQなしではやってら れなくなっちゃいます｡
導入手順
導入手順といってもビルド版なので基本はダウンロードするだけです｡
これをダウンロードして解凍して起動するだけです｡
Thanks Kevin!!11!!
日本語問題対応手順
ですがこのままでは日本語で文字化けしてしまいます｡ 以下のようにして解決しましょう
環境変数設定
Mercurialで使用する文字コードを決めるには環境変数にHGENCODING=utf-8を設定をすればよいです｡
ですがただ ターミナルから設定してもMacの各アプリケーションには有効にならないので グローバルな値として設定しましょう｡
まずは以下のファイルを管理者権限で作成します｡
- /etc/launchd.conf
そしてそこに､以下のように環境変数の設定を書いてやります｡
- setenv HGENCODING utf-8
あとは再起動するだけです｡
この記事に助けられました(SnowLeopardでしたがうまくいきました)
Mercurialユーザーの春がきた
Note
この手順を適応すれば例えば Mac + Pycharm(Python向けのIDE) + Mercurialの連携時に 発生する日本語問題にも対応できます(Pycharmからannotateしたら文字化けしたりしますよね)｡