Vcpkg

Vcpkg は、Visual C++ でオープンソースのライブラリをパッケージとして簡単に管理できるツールとして Microsoft がさいきん公開したツール。GitHub で公開されている。

有名どころのライブラリはほとんどがすでにポートとして網羅されていて、boost、curl、gettext、gtk などを vcpkg コマンドを使って VC++ で使うためにビルドできる。個人的に気になるのは freetype, icu, opencv, openssl, python3, wxwidgets あたりかな。これまで NuGet にもあった WTL はこっちにもある。

オープンソースのライブラリはメインターゲットがほとんど Linux なので Windows で使おうとすると README 読んで自分でがんばるしかないという状況だったので、MS 謹製でこういうものを用意してくれるとありがたい。Visual Studio でこれらを扱う標準的なやりかたが出たのも大きい。

たとえば、ひみつメモ帳は OpenSSL と(現在公開しているバージョンでは)wxWidgets を使っているのだけど、それぞれ自力でビルドしてプロジェクトの設定にマニュアルでパスを追加している。これが、コマンドラインで vcpkg install openssl wxwidgets とだけ叩けば、プロジェクトのソースで #include <openssl/crypto.h> といきなり書けるようになる。ビルドの設定じゃなくてコードに集中できてよい。

気になるのは、OSS のライブラリに交じって、ATL とか MFC とかのポートが含まれているところ。あんまり使う機会はなさそうだけど、やるとどうなるのだろう。

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 のほうで対応してくれないものかなあ……。僕の力量ではどうしていいのかわからん。

pip 非対応のモジュールを virtualenv で使うには(POSIX 編)

Windows 編の続き。

Windows ではハードリンクとジャンクションで行ったが、Linux や OS X など、POSIX の環境であればハードリンクとシンボリックリンクで同様に対策できる。じつは Windows 編で紹介したスクリプト(redirect-package.py)は、すでに POSIX 環境ではそう処理するようになっている。

Linux ではこれで問題ない。

ところが、OS X ではこれで wxPython を使えるようにしようとすると virtualenv 環境では wx モジュールをインポートできない。次回にはこれについて書きます。