TL;DR

GitHub ではリポジトリを Transfer ownership すると、旧リポジトリへのアクセス時に新リポジトリにリダイレクトするようになる。

GitHub リポジトリにアクセスするとリダイレクトすることがある

気づいてる人も多いと思うんですけど、たまにあるんです。

https://github.com/defunkt/hub -> https://github.com/github/hub
https://github.com/lestrrat/peco -> https://github.com/peco/peco

yuya-takeyama/woothee-php も woothee/woothee-php にリダイレクトさせたいと思って、リポジトリの Setting を探してもそれらしき設定はなし。
代わりに、yuya-takeyama/woothee-php に moved ブランチを作って、README.md に「引っ越しました」的なリンクだけ置いていました。
それも woothee/woothee-php からわざわざ fork した上で。

ところがさっき Twitter で教えてもらった情報によると、そんなことする必要なかったんですね。

まぁいま確認したら、Transfer repository するときに、しっかりその旨書かれてるんですが。

Transfer repository するところ

Transfer repository するところ

というわけで、fork して作った yuya-takeyama/woothee-php を削除して、再度アクセスしたところ、見事に woothee/woothee-php にリダイレクトされるようになりました。
めでたしめでたし。
もちろん 301 Moved permanently ですね。

で、試しに git clone https://github.com/yuya-takeyama/woothee-php とかすると、見事に woothee/woothee-php の HEAD が clone されました。
ついでに git remote show origin すると Fetch URL とか Push URL とかは yuya-takeyama/woothee-php になっていて、せっかくだから woothee/woothee-php にしてくれてた方がよかったんですけど、ここは git clone のリダイレクトの扱いの問題ですね。
ちなみに SSH からの git clone でも同様でした。

しかし、これなら Transfer ownership したら Gemfile とかで GitHub からインストールしていた gem がいきなりインストールできなくなった!なんてことは起こらないわけですね。
無意識にやってくれて親切。

あと、リダイレクト先の URL なりリポジトリなりを自分で設定できるような仕様もあり得たとは思うんですけど、まったく関係ないリポジトリとかにリダイレクトさせないようにこういう仕様なんでしょうね。

あわせて読みたい

How to transfer a repository

先週はビッグデータ時代の非ビッグデータ戦略として, MySQL でサクッと MapReduce する話を書きました.
しかしよく考えると, 非ビッグデータを前提とする以上は, やはり普通に GROUP BY とかで済ませてしまうのがよりカジュアルと言えます.

しかしそれをどう見せるか, ということを気にしだすと, これが何気にめんどくさい.
集計時にメールで報告しつつ, 管理ツールのダッシュボード的な画面でも閲覧可能にしたい, という要求はどこにでもあると思いますが, そのときどきで書いていると, クエリを書く何十倍もの時間がかかってしまったりします.

そこで, 例えば RDBMS の結果セットを与えると, それをサクッと見やすく出力してくれる Tablr というのを書きました.
The MIT License にて GitHub で公開しています.

yuya-takeyama/Tablr – GitHub

今どき PHP5.2 で書かれていますが, その辺は何となく察して下さい.
大した機能は無いですが, 個人的にはこれで日頃の問題をいくつか解決できそうなので, 明日からの仕事に使っていく予定です.

使用例

以下は二次元の配列をもとに, プレーンテキストの表を出力するスクリプトです.

ちょっと長く感じますが, require_once や表のデータの部分を除けば, 表の出力に関しては 5 行ほどしかありません.
ここではデータを直接記述していますが, 実際は RDBMS に対して SELECT クエリを発行したときの結果セット等を与えることを想定しています.

これを実行すると以下のような表が出力されます.

以下では Tablr の機能についてより詳細に紹介します.

フォーマッタ

二次元の配列をもとに, いくつかの形式に出力するためのものです.
これが Tablr を作りにあたっての一番のモチベーションとなっています.

現在利用可能なフォーマッタは以下の 2 つのみとなっています.

  • プレーンテキストフォーマッタ
  • HTML フォーマッタ

アグリゲータ

それぞれのカラムで集計を行い, テーブルのフッタにその行を追加します.
現在利用可能なアグリゲータは以下の 2 つのみとなっています.

  • 合計アグリゲータ
  • 平均アグリゲータ

とりあえず必要最低限の機能を実装した, という感じで, 作り込みはかなり甘い感じです.
使えそうな感じであれば, またさらに改善して行きたいと思います.

,

2011-01-03 19:30 追記
rack-config は現在では rack 本体の gem に含まれており, わざわざインストール必要はありませんでした.
(GitHub で送っていた Pull request も閉じてます)
ですが, この記事で紹介している Bundler についての説明は特に問題ありません.

お正月休みということでちょっとした Sinatra 製の Web アプリケーションをいじって遊んでいます.

ローカルでは Pow で開発して, Heroku へのデプロイを考えているんですが, 設定をどう管理するか迷いました.
いろいろ調べた結果, .powenv とか使う方法とかあったのですが, .powenv は Heroku 上では使えません.
どうしたものかとさらに探した結果, rack-config という gem があったのでそれをラップして何とかすることにしました.
(以降はエントリの内容から脱線するので省略. いい感じの方法があれば Twitter とかで教えていただけると幸いです.)

さっそく Gemfile を書いて必要な gem を用意しましょう.
趣味の開発ですし, rack は最新バージョンを指定して, あわよくば地雷を踏み, パッチなど書いて Pull request を送りたい, というのが人情というものでしょう.

これで bundle install を実行すると, 以下のようにエラーで中断してしまいます.

bundle install に失敗

bundle install に失敗

これは rack と rack-config の互換性による問題です.
rack-config は 2012 年 1 月 2 日現在で丸 3 年程メンテされていない状態で, 依存する rack のバージョンが ~> 0.4 と, かなり古い状態です.
(~> 0.4 というのは 0.4.0 以上 0.5.0 未満という意味です)

今回指定した rack 1.4.0 は, rack-config が依存するバージョンに含まれないため, 依存関係の解決に失敗し, エラーとなってしまいます.

といっても, これはメタ情報におけるバージョンの指定の問題で, 実際に互換性があるかどうかは別の問題です.
rack-config の実装は README よりも短くシンプルなもので, 目 rackup した限りでは間違いなく動きそうに見えます.

作者に依頼して依存関係の指定を修正してもらうという手もありますが, 今回はとりあえずの解決をするための方法を紹介します.

大まかな手順

  1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
  2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
  3. 自分のリポジトリに git push する
  4. Gemfile で自分のリポジトリを指定する

Bundler は RubyGems.org からのインストールだけでなく, Git リポジトリからのインストールにも対応しています.
それを利用し, オレオレ Rubygems パッケージリポジトリを作って, そこからインストールしよう, というものです.

今回はたまたま元のプロジェクトが GitHub 上にあったので fork するだけで済みましたが, GitHub 上に無い場合も, 手動でリポジトリさえ作れば, あとは同様の手順で実行できます.

1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する

clone については省略しますが, ブランチを切るのがいいでしょう.
一時的なリポジトリということで, tmp-repo という名前にしてみました.

2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する

*.gemspec というのは, Rubygems パッケージのメタ情報を定義するファイルです.
依存関係もこのファイルに記述されています.

今回の場合は rack-config.gemspec に以下のような修正を加えました.

rack-config は rack 0.4.0 以上 1.5.0 未満に依存する, ということになったので, rack 1.4.0 も含まれるようになりました.

3. 自分のリポジトリに git push する

特に説明は要らないと思いますが念のため.

4. Gemfile で自分のリポジトリを指定する

先ほどの Gemfile を以下のように書き換えました.

fork した自分のリポジトリの URL と, 今回のために作成した tmp-repo ブランチを指定しています.

あとは最初と同じように bundle install を実行するだけです.

bundle install に成功

bundle install に成功

無理矢理 bundle install することに成功しました!

蛇足: オレはこう思う

今回はオレオレリポジトリを作ってとりあえずの解決を試みる方法を紹介しましたが, せっかくなら作者にも修正を出しておくとよりいいでしょう.
今後その gem を使用するときにいちいちオレオレリポジトリを指定するのは面倒ですし, 他の人にとってもその gem がメンテされた状態で使える方が便利です.

今回の rack-config についても, 実際は以下のような手順を経ています.

  1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
  2. ローカルの develop ブランチ上で Bundler を使ってテストできるように修正する
  3. GitHub 上で Pull request を送る
  4. develop ブランチから tmp-repo ブランチを作成する
  5. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
  6. 自分のリポジトリに git push する
  7. Gemfile で自分のリポジトリを指定する

修正を依頼しつつ, それとは別のブランチをオレオレリポジトリにしています.
(この Pull request が取り入れられるのかはまだわかりませんが…)

ついでに Travis CI で 0.4.0 以上 1.5.0 未満の全ての rack でテストが通ることも確認済みです.

Travis CI 用の設定ファイルは以下のようなスクリプトで, .travis.ymlgemfiles を生成しました.
Travis CI では複数の gemfiles を指定することで, それぞれで bundle install し, 複数のバージョンの gem に対してテストを行うことができます.

なお, rack は 0.4.x のあといきなり 0.9.x にバージョンが飛んでいます.

これで, 見事に全てのバージョンでテストが通ることが確認できました.
(ここまで必死になることも無いとは思いますが…)

, ,