TokyoMercurial No.10
昨年末は、色々バタバタしてしまい、年が明けてからエントリを書いてます…… orz
TokyoMercurial No.10 に参加してきました。
運営の id:troter 氏ならびに参加者の皆様、お疲れ様でした。
作業目標&消化状況
今回の TokyoMercurial の個人的な目標は、以下の2件です。
- 3.2.2 向けのメッセージ翻訳の実施
- 積み残している TODO リストの消化
前者に関しては、更新された翻訳対象メッセージが少ないこともあって、比較的簡単に翻訳&反映は完了。
後者に関しては、2013年のバックログから選んだ作業をやっていたのですが、何故か周辺事情で、微妙な挙動を見つけてしまい、専ら本来の作業目標とは別の部位を掘り下げる羽目に。まぁ、いつもの地雷踏体質健在ナリな感じですね(笑)
結局こちらに関しては、微妙な進捗でしたが、トライ&エラーという名で色々こねくり回したことで、良い感じの修正案が見えてきたので、まぁ、良しとしましょう、という感じに。
気になった話題
● バージョン横断で利用可能なエクステンション
Mercurial は、コマンドラインレベルのインタフェースの恒常性を謳う一方で、内部 API の恒常性は無保証で、その利用は非推奨であることを明言しています。
そのため、ある程度込み入った処理を行うサードパーティ製のエクステンションは、Mercurial のバージョンによる内部 API の違いを意識する必要があります。
hasattr
を使った、変数・関数・属性等の有無判定での切り分け- inspect.getargspec() を使った、関数引数の差異での切り分け
といった手法を用います。
既存クラスの処理をフックするようなケースでは、propertycache アノテーションの有無/種別等で切り替えが必要なケースがあるかもしれません。
● Mac OS でのインストール
make install
とか setup.py
でインストールする際に、--prefix
指定でインストール先を変更できます。
例えば私の場合、--prefix ${HOME}/hg/バージョン
のような感じで、複数の Mercurial を平行して使えるようにしたりしています。
しかし、Mac OS X で homebrew の Python を使った場合、--prefix
を指定しても:
という謎の挙動になるんですよねえ。
Xcode 付属の Python や、他の POSIX 環境では、指定通りの場所にインストールしてくれるので、homebrew の Python 処理系か setup-tools 周りのパス設定が、他と違っているのではないかという気が。
いずれ原因を特定しておきたいところなのですが…… > TODO
● commit 処理の拡張方法
オリジナルの hg-geo では、折角commitctx を書き換えているのに、位置情報はコミットログに追記する方式だったので:
def commitctx(self, ctx, error=False): extra = ctx.extra() if 'location' not in extra: extra['location'] = 位置情報 # オリジナル処理の呼び出し return super(geo_repo, self).commitctx(ctx, error=error)
上記の様に extra 領域に書き込んだ方が、位置情報の有無を事後的に検出しやすいメリットがあるよ、という話に。
コミットログへの追記だと、「たまたま似たような形式の末尾テキスト」も位置情報とみなしてしまう可能性が排除できませんが、extra 領域だと位置情報の有無判定や取得が確実に実施できます(名前の衝突には配慮が必要ですが……)
この方式であれば、revset の orig() や dest() と同じ要領で「位置情報を使った revset 問い合わせ」とか、夢が広がります(笑)
● ウェブ UI の簡易利用
[http://mercurial-users.jp/manual/hg.1.html#serve:title=hg serve]
で簡易 HTTP サーバが起動できるので、簡単な動作確認等であれば、実は外部の HTTP サーバを別途用意する必要はなかったりします。
なお、デフォルトの設定では、HTTP 経由での push は受け付けないので、必要に応じて web セクションの push_allow
等を設定する必要があります。