Jinja2 テンプレートのオブジェクトを JSON ファイルで指定してテキストを出力できる Python スクリプト（兼モジュール）を作りました。
jsonjinja · PyPI
jjtemplate · PyPI
まあぜったい世の中のだれかがもう作ってるだろうけどいいんだよ。
あと名前も気に入ってます。ジェイソン神社。
2024-10-14 追記
GitHub に同名のプロジェクトがあったので混乱を避けるため jjtemplate に改名しました。
ウェブアプリ開発をローカルでやるかコンテナでやるか
VSCode で Python ウェブアプリケーションを開発するとき、コンテナの活用という視点で見るとつぎのように分類できる。
ローカルで開発、デバッグ
古典的なやりかた。プロジェクトをチェックアウトして、venv を作ってコードを書く。デバッグ（実行）するときもローカルのマシンで venv の Python で動かして確認する。いちばんなじみがある。
ローカルで開発、コンテナでデバッグ
VSCode ではデバッグ時にコンテナでプロジェクトを走らせることができる。ウェブアプリなんて作ったらどうせ（？） Dockerfile 書いてコンテナで動かすんだからはじめからコンテナで動作確認したほうがいい。後述の Dev Container が出るまでは有力な選択肢だった。
コンテナで開発、デバッグ
Dev Container ができて、最初から実行環境に近いコンテナでぜんぶ開発できるようになった。コンテナの中でローカルのように開発、デバッグできる。VSCode すごい。
Dev Container 開発の利点は、“What’s a devContainer and what is it good for?” (2023) という記事で次のような点が挙げられている。
- 必要な開発環境をすぐに用意できる（依存ライブラリのインストールなどをあらかじめ揃えておける）。
- 開発環境のバージョンを固定化できる。手元のマシンでは最新版にアップデートしたランタイムが後方互換性を失っているときなどでも以前のバージョンで開発を再開できる。
- データベースなど連携するコンポーネントもコンテナに含めてしまうことで、実環境の変更の影響が開発環境に及ばないようにできる。開発者は各自自分のコンテナでの DB との接続性を保ったまま開発に集中できる。
で、ここではじつは開発環境が実行環境に近いということはとくに謳っていないのだが、たとえばプロジェクトで利用しているあるライブラリが Linux のみ対応だったり、Windows / macOS では挙動が違ったり、ディレクトリ構成が異なることで面倒な対応が必要だったりというのはありがちな話なので、そういうことから解放されるのはけっこう大きいメリットではないかと思う。
wxPython は PyPI にある
昨年書いた wxPython を pip でインストールする話の続編。
当時は pip コマンドに wxPython 公式サイトの URL を指定してごちゃごちゃやっていたのだけど、ちょっと前に正式に PyPI に登録された。いまは、
pip install wxPython
でインストールできる。Windows もビルド済み wheel があるのでかんたん。
wxPython（Phoenix）を pip でインストール
Phoenix は wxPython をモダンにリファインしているプロジェクトである（同じ名前のソフトウェアプロジェクトたくさんあるけど）。wxPython 開発陣自身によって進められている。モダンとはなにかというと Python 3 対応とか pip 対応とかである。ずっと開発版で表には出てこないのだけど Dropbox などはたしかすでに使っていた気がする。
wxPython が Python 3 や pip に対応していないのはけっこう面倒で、できればはやく正式版になってもらいたい。ようやく試したのでメモ。
Phoenix はまだ PyPI には登録されていないので、プロジェクトのウェブサイトにホストされているスナップショットからダウンロードする。ウェブサイトが HTTPS 接続できないので pip にはそのためのオプション –trusted-host が必要。また、バージョンが開発版なので –pre も要る。
~/src/test % pip install --user --pre --trusted-host wxpython.org -f http://wxpython.org/Phoenix/snapshot-builds/ wxpython-phoenix Collecting wxpython-phoenix Downloading http://wxpython.org/Phoenix/snapshot-builds/wxPython_Phoenix-3.0.3.dev1839+4ecd949-cp27-none-macosx_10_6_intel.whl (29.5MB) 100% |████████████████████████████████| 29.5MB 1.4MB/s Installing collected packages: wxpython-phoenix Successfully installed wxpython-phoenix-3.0.3.dev1839+4ecd949 ~/src/test % pip list --user wxPython-Phoenix (3.0.3.dev1839+4ecd949)
wheel 版が用意されているので Windows でもビルドが要らないのがよい。
pip 非対応のモジュールを virtualenv で使うには（OS X 編）
Windows 編、POSIX 編の続き。というかこれが本題。
これまで説明してきた方法でシステムにインストールしたパッケージやライブラリを virtualenv 環境にリダイレクトできるのだけど、このやりかたを使って OS X で wxPython を使おうとすると、以下のような奇妙なメッセージが出てうまくいかない。
This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac.
どうも OS X の Python は特定の場所にインストールされているバイナリでないと GUI のフレームワークなどを使うことができないらしい（適当な推測）。virtualenv は作業ディレクトリにインタプリタをコピーするのでそれではじかれるようだ。
これは困った。コピーしたインタプリタが使えないんじゃ virtualenv できないじゃないか。で、あれこれ考えたのだけど、環境変数 PYTHONHOME を設定してもとの python を実行すれば別の環境でインタプリタを起動できることに気づいた。virtualenv 環境が /path/to/venv ディレクトリにあるなら、PYTHONHOME を /path/to/venv にして /usr/bin/python を実行すれば、virtualenv と同等のカプセル化の恩恵が得られる。
そこで、activate.csh に（tcsh なんすよ……）、PYTHONHOME を設定するような記述（と、deactivate したときにそれを戻す記述）を追加してみた。それから、virtualenv が作った作業ディレクトリの python コマンドの代わりに、システムの python へのシンボリックリンクを置く。
ln -s /usr/bin/python /path/to/venv/bin/
改造した activate.csh は Gist に置きました。bash 用のスクリプトをだれか作ってあげてください。
それはさておき、こうするとそれまでの virtualenv と同様の使い勝手で開発を続けることができる。めでたい。
めでたいのだけど、virtualenv 環境を作るごとにこの作業をするのは面倒くさい。なんとか virtualenv のほうで対応してくれないものかなあ……。僕の力量ではどうしていいのかわからん。