Open ukyooo opened 8 years ago
対応後に下記にてリポジトリを登録。
woothee-php のように、 DataSet.php を submodule から生成する方式の方が手っ取り早そうに見えるんですが、あえて source-data を composer に登録する意図はなんなんでしょう?
いや、これは大分無理矢理な気がします。
せっかく、 submodule ( .gitmodules ) でデータを分離させて管理しているのに、こうしてしまうと woothee
の更新に合わせて woothee-php
も更新が必要となってしまう為、
できれば zengin-code
の方では source-data
の更新は zengin-php
に影響がない(もちろん、データのスキーマ自体に変更が入ってしまったら影響を受けますが)状態にしておきたいと考えています。
composer 自体に手を入れて、 .gitmodules
があった場合、引きこむようにする、とも思ったのですが、
https://github.com/composer/composer/pull/1600
で、ブーイングを受けてリジェクトされてました…。
woothee の更新に合わせて woothee-php も更新が必要となってしまう為
現在 zengin-rb も zengin-js もそうやって運用しているので、悪いとは思っていません(source-data の変更に追従して両方のバージョンがあがる)。
依存が増えることと、 source-data という独立したリポジトリを PHP 用に改変することの2点を超えるほどの利益をイマイチ見いだせていないです。
更新作業そのものは CI 上で自動化している(し、 PHP 版も同様に自動化する)ので、メンテナンスコストという意味では問題ないかなとも思っています。
ちょっと composer の仕組みがわかってなくて理解が甘い気がしているので、少し勉強してきます。
レスが遅くなってしまっており、申し訳ありません。
今週中には回答します。 (※現在、本業の方が忙しなってきてまして…。)
こちらの状態ってどうなってるでしょうか? PHPユーザですが、使おうと思っても使えなくて困りました。。。
マージがずっとされてない状態だったのもあり、私自身でも試しに作ってみました。 https://github.com/fagai/zengin-php
まずsubmoduleで試しましたが、composerがsubmoduleに対応しないため不可能でした。 次に自分自身のcomposer.jsonに設定を書く方法をやってみましたが、こちらも実際に公開した状態で取得される際には使えないことがわかりました。https://getcomposer.org/doc/faqs/why-can%27t-composer-load-repositories-recursively.md
jsの場合はビルドを通すことでsubmodule問題を解決していますが、phpの場合はビルドの概念が無いので難しいです。
また、依存性という話が出ていますが、composerはcomposer.jsonを追加してpackagist.orgに登録するだけなので、影響度は低いと思います。
@fagai 以前の回答と同様で、 woothee-php と同様にデータセットの PHP を生成する方式を実装しない理由がなく、また source-data は『特定の言語のための実装』を入れるべきでないと強く考えているため、このリポジトリに composer.json を追加することはありません。 ccomposer.json の更新で他言語実装のリリースが走ることは許容できないためです。
なるほど。。。承知しました。
composer を使用し、
zengin-code/source-data
を取得できるように対応する。以下のイメージで、
zengin-php
をインストールする際にcomposer.json
に一緒に追記し、 composer install / update で引き込めるようにする。git submodule で取得するようにしたかったが、 composer install や update をトリガにコマンドを実行する手段はあるものの、インストールされるモジュール側に設定されたコマンドは実行することできない為、上記の手段で対応する。