トップ > Trac

プラグインとログ出力と認証機構と

SourceForge.net Trac

SourceForge.netにTracを入れようとやってた理由は、XML-RPCプラグインを入れてMylynと連携させたかったから。で、XML-RPCプラグインが入れられないとほとんど意味がないんで、その辺りにチャレンジしてみた。

  1. まず、TracにXML-RPCプラグインを入れてみる。

Tracは1システムに複数のプロジェクトをインストールできる。*1それからTracのプラグインはシステム全体に入れるか、プロジェクトに入れるかを選択できる。システム全体と書いたが、Tracのディレクトリというわけではなく、Pythonの共有パスに追加される様子。共有パスは大抵インストールディレクトリのLib/site-packeges/以下のなので、システム全体にインストールできない。

昨日の日記で、SourceForge.netにCGIをインストールした場合、CGIからファイルを書き込む場所は/tmp/persistent以下にプロジェクトのディレクトリを掘って、その下を指定すると記載しましたが、これはどう考えても一時フォルダとして指定してねという意図が感じられるわけです。なので、Tracのログを出力させるだけとか、常用すべきではなさそうです。

それでもプラグインのキャッシュを出力するフォルダを/tmp/persistent/ProjectName以下に指定することでプラグインが解凍され使えるように。

続いて認証機構
SourceForge.netでは

GroupName/cgi-bin

にCGIを置くと固定されていますので、.htaccessを使って権限を調整するしかありません。とりあえずcgi-binの下にloginってディレクトリを掘って、そこに.htaccessを置いてみました。でもそもそもTracってScriptAliasを使ってあるURIをTracのパスとする設計だから、それだけじゃどうにもならんわけで、結局思いついたのが、loginの下にもう一個trac.cgiを置いた。

そしてリンクを貼るためにtracのweb/href.pyにloginというメソッドを追加するという無理やりなコード。

*** href.py.org 2007-04-20 06:41:51.000000000 -0700
--- href.py     2007-10-27 06:58:23.000000000 -0700
***************
*** 157,163 ****
          if not self._derived.has_key(name):
              self._derived[name] = lambda *args, **kw: self(name, *args, **kw)
          return self._derived[name]
!

  if __name__ == '__main__':
      import doctest, sys
--- 157,165 ----
          if not self._derived.has_key(name):
              self._derived[name] = lambda *args, **kw: self(name, *args, **kw)
          return self._derived[name]
!
!     def login(self):
!         return '/cgi-bin/login/trac.cgi'

  if __name__ == '__main__':
      import doctest, sys

こんな感じなんですが、「!」って衝突ってこと？
「+」じゃないとパッチとして当たらない気がするんですが、とりあえずこのままさらしておきます。

*1:ついでに言うと、1システムに複数バージョンのTracを入れられそう。それは後々

エレガントなスクリプト

Trac SourceForge.net

id:moriyoshiさんの日記にTracをSourceForge.netにて動かすという記事があり、そこを参考にここ数日それを読んで踏ん張っていたのですが、やっぱなんともなんないやと諦め、moriyoshiさんのところにコメントで質問を書きました。すると快く記事に追記をしていただけました。

で、trac.cgiやパッチを読んでみて、自分の不勉強を再認識しました。
Shellも書くの楽しいけど、それ以上に読むことが楽しいんです。
Code Readingっていうぶあっつい本がありますが、
あれの勉強会とかやってみたいですね。

trac-hacks.orgふかーつ

Trac

Tracユーザーのみんなが待ち焦がれていたtrac-hacks.orgが復活したよ。

担当者の人がサーバーダウン中に一ヶ月間休暇で海外に出ていたため、
ここ数日ずーっと止まっていた。
あんなプラグインやこんなマクロを探してみよーっと。

SourceForge.netで作ったプロジェクトにTracを入れて使ってみる(その2)

SourceForge.net Trac

本日の結論:SQLite3がうまく動かないので、Trac的には危ないにおいのするMySQLに手を出してみる。

SourceForge.netのシェル環境まとめ

  • プロジェクトのディスクスペースは100MBまで。
  • ユーザーのディスクスペースは5MBまで。
  • DBとしてMySQLが用意されている。
  • MySQLはプロジェクトごとに作成でき、基本100MBまで。
  • コンパイル用の環境はない。

ディスクスペースについては実際はそれを超えてもしばらく使えるようだ。しかし消されるときは通知なく、容赦なく消すよと書かれているので、ディスクスペースの限界を越えないように気をつける。
また、GCCなどもインストールされていないので、バイナリが必要な場合は他の環境でコンパイルされたものを用意する必要がある。

Tracの動作に必要なソフトウェアのバージョン

ということで、SQLite3のバージョンを更新して、python-clearsilverを入れてみようと試みた。
Setting Up Trac on CentOSを参考に、
Dag Wieers' repositoryからパッケージを落としてきては、解凍し、自分のユーザーエリアでpysqlite2を動かそうとしてみたが、ファイルDBに書き込むところでどうしてもハングアップしてしまう。ということと、元々プロジェクトごとにMySQL 4.1が用意されているので、あきらめてMySQLで導入できないか、試みることにした。


今日のわかったこと

  • SQLite3の本体は動的ライブラリで、LD_LIBRARY_PATHで更新先のディレクトリを指定しないと、バージョンがあがらない。
  • python実行用の環境変数PYTHONPATHを使ってパスを指定すると、指定したパスからモジュールの参照をしてくれる。setuptoolsでインストールできないような環境で重宝する。例
export PYTHONPATH=/home/users/k/ko/kompiro/centos/usr/lib/python2.3/site-package
  • 各コマンドを実行する前に環境変数を渡すことができる。例えばこんな感じ
LD_LIBRARY_PATH=パス1 PYTHONPATH=パス2 python

SourceForge.netで作ったプロジェクトにTracを入れて使ってみる(その1)

Trac

といってもまだ全然できてないですが。
ぱっと調べてみた感じ、結構がっつりやる気にならないとできなさそうです。
情報源のメモ程度のエントリです。

以下メモ

　ここでsourceforgeで検索すると結構釣れる。どうもDebianからパッケージを抜き出すのが賢い漢のすることらしい。

Debianのパッケージなんて、どうやってとってくるの？という疑問に多少答えてくれたDebianパッケージ一覧。aptitudeとか、dpkg使えば依存性も解決しつつダウンロードできるじゃんというツッコミは、どこにダウンロードされるかわかんない僕には受けられませぬ。