XREAで好きなバージョンのPythonを使う方法

前のエントリーから自作のブログソフトに移行してみたわけだけど、やっぱり自分で作ったものはなんとなく気持ちいいですね。

さて、このブログはXREAでPython2.5で動いているわけですが、もちろん？XREAにPython2.5ははいっていません。ではどうやって動かすか･･･というと答えは簡単。バイナリとして動かしているわけです。

XREAはバイナリCGIが動くのでバイナリにしてしまえばどんなバージョンのPythonでも問題ありません。しかも、たとえばMySQLDBなどの拡張モジュールもきちんとバイナリに含まれるので、多少ファイルサイズは大きいですがアップロードするだけで動くので非常に楽です。

今回はXREAでローカルで作ったPython2.5アプリをバイナリ化して動かすまでを紹介しようかと思います。

バイナリ化ライブラリ：bbfreeze

バイナリ化に使うライブラリですが、俺はbbfreezeを使いました。bbfreezeの特徴は

  • すごく簡単
  • ライブラリの探索に優れる
  • Linux用バイナリが作れる

というところでしょう。

bbfreezeを使う上での注意点

ただ、使う上で色々注意点もあります。書きなぐりなのでちょっと汚いですが、このブログアプリ用のfreezeスクリプトです。

python code
  1. from bbfreeze import Freezer
  2. import sys, os, shutil
  3. from os.path import dirname, abspath, join
  4. root = abspath(dirname(__file__))
  5. sys.path = [join(root, d) for d in ["libs"]] + sys.path
  6. include_lst = []
  7. for r, dirs, files in os.walk(join(root, "libs")): #指定ディレクトリ以下を全部追加
  8.   if "__init__.py" in files:
  9.     include_lst.append(r)
  10.   for file in (f for f in files if f.endswith(".py") and f != "__init__.py"):
  11.     include_lst.append(join(r, file[:-3]))
  12. def replace(f):
  13.   return f[len(join(root, "libs"))+1:].replace("/", ".")
  14. include_lst = map(replace, include_lst)
  15. include_lst.append("_mysql") # MySQLDBの_mysqlが含まれないので手動で追加
  16. shutil.copy(join(root, "index.py"), join(root, "index.cgi.py")) #cgi用にリネーム
  17. f = Freezer("dist", includes=include_lst, excludes=(), )
  18. f.addScript("index.cgi.py", True)
  19.  
  20. f() # starts the freezing process
  21.  
  22. os.remove(join(root, "index.cgi.py"))
  23.  

と、こんな感じです。ほんと汚いな･･･。さてでは注意点を一つ一つ。

  • できる限り自動的に使用しているライブラリを検索してくれるのですが、__import__で動的にインポートする場合はさすがに無理です。なので、そういうモジュールがある場合、自分で追加する必要があります。このブログアプリではPygments、Markdownあたりが__import__による動的インポートを行っています。
  • MySQLDBの_mysqlモジュールのように探索されないのもありますので、注意しないといけません。
  • 出力されるバイナリファイル名はメインスクリプトから.pyを除いたものになります。XREAでcgiとして動かす場合はあらかじめindex.cgi.pyみたいにリネームしておくとindex.cgiが吐き出されるので便利です。

また、dirname(__file__)でディレクトリを取得し、テンプレートファイル用ディレクトリなどを設定している場合、注意が必要です。以下のようにします。

python code
  1. root_dir = abspath(dirname(__file__))
  2. if "library.zip" in root_dir:
  3.   root_dir = dirname(root_dir)
  4.  
  5. template_dir = os.path.join(root_dir, "templates")
  6.  

ファイルはlibrary.zipにまとめられますので、実行時は/library.zip/hogehoge.pyのような扱いになります。そのためlibrary.zipがパスに含まれる場合はさらに1個上のディレクトリが求めているディレクトリになります。

アップロード

生成されたファイル群をアップロードするだけです。さすがにサイズは大きいですが。もちろんアップした後index.cgiのパーミッションは設定しましょう。

アクセスしましょう

バッチリ動くはずです。

というわけで、bbfreezeを使えばサクッと任意のバージョンのPythonで作ったアプリがXREAで動かせます。あとは負荷だけが問題です。1日見た限りではweb.pyの場合負荷は大丈夫っぽいです。ぶっちゃけ、Wordpressより速い気がします。web.pyはライトウェイトWEBフレームワークとしてもう少し評価されるべき。Djangoとかだとどうなんですかね。チャレンジャーな方は、ゼヒ。

07.29.08/12am
Posted at:
07.29.08/12am
Tags:
Comments:
0
Permalink

試験的に自作ブログに移行しました

前のエントリーでGAEにおけるトランザクションの問題は一応解決をみた。

その後、GAEで開発を続けた結果、やはりGAEにブログを移行するのは断念した。理由としては

  • os.listdirなどで不審な挙動が見られた
  • スキーマを変更したときが非常に面倒
  • インポート、エクスポートの難しさ

が主なところ。

os.listdirについては、web.pyでテンプレートを検索するときにos.listdirを使っているのだけど、どうも動きが怪しい。正しくファイルリストが帰ってきたり帰ってこなかったりするのだ。何回も本番にアップして試したところ、os.listdir("hoge");os.listdir("hoge")というように同じ内容で2回連続で呼び出すとなぜか確実にファイルリストが帰ってくる、という･･･これはちょっと･･･

スキーマの変更に関しては、まんま。変更したとき、それを本番に反映させるのがめんどくさい。

インポートエクスポートも負荷を考えるとしんどい。現在もWEBはレンタルサーバで運用しているのでわざわざGAEにもっていく旨みもない。

ということでせっかくブログをつくったのに移行をやめたのである。

しかし、せっかく作ったのにもったいない。ということで今度はGAE用につくったブログを普通にMySQLを使うようにポーティングした。今回はそれに試験的に移行してみたのだ。

なぜWordpressからわざわざ独自ブログソフトウェアに移行したのか。理由は前のエントリーにも書いたとおりだけど

  • Wordpressのコードが気に食わない（OSSとしてバランスをとっている、というのはあるんですが）
  • 使用しているテンプレートや、プラグインも含めると出力されるHTMLが汚い。
  • ついている機能の半分以上は使っていない。ブログライトユーザの俺には機能が多すぎる。
    • 自分の使う機能が固まった。それさえあれば俺には十分とわかり始めた。
  • セキュリティ的にもWordpressはターゲットになっていて微妙。

以上のようなところをふまえ

  • 明快なコード。
  • キレイなXHTML。
  • 自分が使う機能だけ実装。
  • 堅牢なコード。

ということを心がけた。またレンタルサーバで動かすということで

  • なるべく静的HTMLとしてキャッシュしてmod_rewriteで飛ばす
  • 見た目や外部連携に関する動的な部分はなるべくクライアントサイドで

ということにも気を配った。

このブログは3年目に入るのだけど、やはりWEBの世界というのは流れが速いもので大分変化があった。その中で、外部連携はほぼJSONPで行えるようになったのでサーバサイドでやらなくても良くなった。今回実装したブログでは各SBMのブクマ数を表示しているけど、これも全てJSONPでクライアントサイドで実現している。それに対し、旧ブログ(Wordpress)ではサーバサイドで定期的に取得していた。

という感じで出来上がったのがこのブログだ。もうひとつ、実はこのブログ、XREAでしかもPython2.5で動かしている。あれ、XREAでPython2.5使えたっけ、というあなた。実は簡単に使えちゃうワザがあるんですよ。それについては、また。

あまりテストもせず試験的に移行してみたのでおかしい部分もあるかと思いますが、そこはおいおい。パーマリンクはそのままになっていると思います。基本的にURLは変更していません。また、CGIで動かしていますので、負荷が高ければ前のに戻す予定です。

07.28.08/02am
Posted at:
07.28.08/02am
Tags:
Comments:
0
Permalink

GoogleAppEngineのトランザクションをねじふせる

前のエントリーで書いたように、GoogleAppEngineのトランザクションは使い勝手が悪い。しかし、GAEにブログを移行しようと思うとこれは乗り越えなければならない。

GAEでトランザクションを行う条件を簡単にまとめると

  • db.run_in_transactionにトランザクションとして実行したい関数を渡すがその関数内では
  • 同じエンティティグループに属しているモデルで
  • get, put, deleteのみ

しか実行できない。なのでトランザクションのページに紹介されているような

python code
  1. from google.appengine.ext import db
  2.  
  3. class Accumulator(db.Model):
  4.   counter = db.IntegerProperty()
  5.  
  6. def increment_counter(key, amount):
  7.   obj = db.get(key)
  8.   obj.counter += amount
  9.   obj.put()
  10.  
  11. q = db.GqlQuery("SELECT * FROM Accumulator")
  12. acc = q.get()
  13.  
  14. db.run_in_transaction(increment_counter, acc.key(), 5)
  15.  

先にGQLを発行しておいて、run_in_transactionに渡す関数ではGQLの結果として取得したkeyを引数にとる、という回りくどいコードになる。コレは書きづらい。

これも前のエントリーに書いたように、今回作ったブログアプリでは月別アーカイブやタグアーカイブの記事数をエントリのCRUD時に操作している。

エントリ作成時なら

python code
  1.   @classmethod
  2.   def create(cls, *a, **k):
  3.     obj = super(Entry, cls).create(*a, **k)
  4.     TagCount.inc(obj.status, *obj.tags)
  5.     MonthCount.inc(obj.status, obj.created_month)
  6.     return obj
  7.  

というような感じだ(statusは公開、とか非公開とかが入る)。当然、このcreateメソッドではTagCount,MonthCountとobjについて一貫性が保たれなければならない。しかし、TagCount.incでは対象のタグを検索して、なければ作成しputする、という操作を行う。「対象のタグを検索して」というトランザクション内で許可されていない操作が入っているのだ。

さて、こういうときはとりあえず？力技で乗り切ろう。かなり強引だが、下のようなコードで乗り切ってみた。一応、サーバにアップロードして動作することは確認している。

python code
  1. class RootModel(db.Model):
  2.   id = db.IntegerProperty(default=1)
  3.   def __call__(self, k):
  4.     v = k or {}
  5.     v.update(parent=with_parent)
  6.     return v
  7. with_parent = RootModel.get_or_insert("id", id=1)
  8.  

まず、全てのエンティティを同一エンティティグループに所属させることにする。そのため、全てのエンティティの親となるエンティティを作成する。

次は強引さの根源のようなクラスだ。

python code
  1. class Transaction(object):
  2.   MAGIC_NAME = "__magic__lst__"
  3.   SEARCH_MAX = 12
  4.   def __init__(self, f):
  5.     self.f = f
  6.  
  7.   def execute(self):
  8.     __magic__lst__ = []
  9.     result = self.f()
  10.     def commit():
  11.       for dbop in __magic__lst__:
  12.         dbop()
  13.       return True
  14.     committed = db.run_in_transaction(commit)
  15.     if committed is None:
  16.       raise db.Rollback()
  17.     return result
  18.  

これだけでは分からないと思うが、execute内でrun_in_transactionが実行されている。その引数にはcommit。commitの中では__magic__lst__というリスト内の関数を実行しているようだが、__magic__lst__に要素が追加されている形跡がない。

そして、全てのモデルの親となる基本モデルを定義する。

python code
  1. class BaseModel(db.Model):
  2.   @classmethod
  3.   def create(cls, *a, **k):
  4.     obj = cls(*a, **with_parent(k))
  5.     obj.put()
  6.     return obj
  7.  
  8.   def _with_transaction(self, name):
  9.     i = 1
  10.     f = sys._getframe(i)
  11.     while f and i < Transaction.SEARCH_MAX:
  12.       if Transaction.MAGIC_NAME in f.f_locals:
  13.         f.f_locals[Transaction.MAGIC_NAME].append( \
  14.           lambda : getattr(super(BaseModel, self), name)())
  15.         return
  16.       i += 1
  17.       f = sys._getframe(i)
  18.     return getattr(super(BaseModel, self),name)()
  19.  
  20.   def put(self):
  21.     return self._with_transaction("put")
  22.  
  23.   def delete(self):
  24.     return self._with_transaction("delete")
  25.  
  26.   def update(self, **k):
  27.     for prop in self.properties().values():
  28.       if prop.name in k:
  29.         prop.__set__(self, k[prop.name])
  30.     self.put()
  31.  
  32.   @classmethod
  33.   def get_by_id(cls, id):
  34.     return super(BaseModel, cls).get_by_id(id, parent=with_parent)
  35.  

この基本クラスではまず、createというメソッドを定義し、エンティティはすべてこのメソッドを通して作成するようにしている。createでは必ず親エンティティとしてwith_parentを指定する。これにより全てのエンティティは同一エンティティグループに属することになる。

  • 同じエンティティグループに属しているモデルで

という条件はクリアしたことになる。次は

  • get, put, deleteのみ

という条件だ。これは_with_transactionというメソッドでクリアしている。putとdeleteをオーバーライドして_with_transactionを呼び出すようにしている。さて、この_with_transactionではフレームをさかのぼって、__magic__lst__という名前のローカル変数が存在するフレームがないか探索する。そのフレームが存在した場合、一連のトランザクション内での実行とみなし、__magic__lst__にput,deleteを行うthunkを登録し、終了する。存在しない場合は通常の実行ということで、その場でput, deleteを行う。つまり、トランザクション内で実行されたことを検出してput, deleteの評価を遅延させるのだ。

さきほどのcreateは

python code
  1.   @classmethod
  2.   def create(cls, *a, **k):
  3.     def _():
  4.       obj = super(Entry, cls).create(*a, **k)
  5.       TagCount.inc(obj.status, *obj.tags)
  6.       MonthCount.inc(obj.status, obj.created_month)
  7.       return obj
  8.     return Transaction(_).execute()
  9.  

と若干のコード挿入のみできちんと一貫性が保証されるようになる。

というわけで、かなり強引な気がするけどトランザクションの問題は一応クリアされた。めんどくさければHTTPリクエストを受けてから、レスポンスを返すまでを関数でラップし、Transaction.executeすれば大丈夫だ。

ここまでやってしまったので、やっぱり今のブログはGAEに移行しようかなあ、と思い始めたり。デザインも今と似ているけどやっぱ一から自分でマークアップしたから好みだし、なによりXHTMLとしてValidだ。機能的にはあと、スパム対策さえあれば大丈夫。

実はOpenIDも自分でサーバ立ててたりするので、それもGAEで実装しなおしたいなあとか色々やりたいことは尽きない。GAEでの開発はこのモデルの問題さえつぶしてしまえばかなり楽だし、夢がひろがるなあ。

07.27.08/12am
Posted at:
07.04.08/02am
Tags:
Comments:
0
Permalink

About

Author:yuin(http://inforno.net/)

文学部文化学科卒という生粋の文系趣味プログラマ。

主にRuby、Javascript、PHP、JAVA,Python,C,Scala,Schemeなどを使っています。今はPythonな感じかもしれない。今後作曲活動なども復活するかもしれない。

Links

Pages

Recently

Tags

SF1 activesupport1 api3 binary3 blog1 book1 cltc1 compiler1 craftlaunch2 cui1 development9 drecom1 electronics1 emulator6 erlang1 essay9 fckeditor1 feed1 gae3 gui2 javascript14 job4 language1 library10 life4 lingr1 linux1 nes5 network1 nicovideo1 nlp1 ocaml1 parser6 programing2 prototype_js7 python33 python30001 ruby5 rubyonrails2 scala6 scheme1 scrap1 scriptaculous1 sexp1 tasktools1 template2 text2 tk1 typo2 vim2 webpy2 windows3 wordpress2 xrea1 yahoo3

Monthly Archives