Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zengin-code/source-data の composer 対応 #1

Open
ukyooo opened this issue Mar 24, 2016 · 9 comments
Open

zengin-code/source-data の composer 対応 #1

ukyooo opened this issue Mar 24, 2016 · 9 comments

Comments

@ukyooo
Copy link

ukyooo commented Mar 24, 2016

composer を使用し、 zengin-code/source-data を取得できるように対応する。

以下のイメージで、 zengin-php をインストールする際に composer.json に一緒に追記し、 composer install / update で引き込めるようにする。

  {
    ...
    "require": {
       ...
+     "zengin-code/source-data": "*",
+     "zengin-code/zengin-php": "*"
    }
  }

git submodule で取得するようにしたかったが、 composer install や update をトリガにコマンドを実行する手段はあるものの、インストールされるモジュール側に設定されたコマンドは実行することできない為、上記の手段で対応する。

@ukyooo
Copy link
Author

ukyooo commented Mar 24, 2016

対応後に下記にてリポジトリを登録。

https://packagist.org/packages/submit

@rosylilly
Copy link
Member

woothee-php のように、 DataSet.php を submodule から生成する方式の方が手っ取り早そうに見えるんですが、あえて source-data を composer に登録する意図はなんなんでしょう?

https://github.com/woothee/woothee-php

@ukyooo
Copy link
Author

ukyooo commented Mar 24, 2016

いや、これは大分無理矢理な気がします。

せっかく、 submodule ( .gitmodules ) でデータを分離させて管理しているのに、こうしてしまうと woothee の更新に合わせて woothee-php も更新が必要となってしまう為、
できれば zengin-code の方では source-data の更新は zengin-php に影響がない(もちろん、データのスキーマ自体に変更が入ってしまったら影響を受けますが)状態にしておきたいと考えています。

@ukyooo
Copy link
Author

ukyooo commented Mar 24, 2016

composer 自体に手を入れて、 .gitmodules があった場合、引きこむようにする、とも思ったのですが、

composer/composer#1600

で、ブーイングを受けてリジェクトされてました…。

@rosylilly
Copy link
Member

woothee の更新に合わせて woothee-php も更新が必要となってしまう為

現在 zengin-rb も zengin-js もそうやって運用しているので、悪いとは思っていません(source-data の変更に追従して両方のバージョンがあがる)。

依存が増えることと、 source-data という独立したリポジトリを PHP 用に改変することの2点を超えるほどの利益をイマイチ見いだせていないです。

更新作業そのものは CI 上で自動化している(し、 PHP 版も同様に自動化する)ので、メンテナンスコストという意味では問題ないかなとも思っています。

ちょっと composer の仕組みがわかってなくて理解が甘い気がしているので、少し勉強してきます。

@ukyooo
Copy link
Author

ukyooo commented Mar 30, 2016

レスが遅くなってしまっており、申し訳ありません。

今週中には回答します。
(※現在、本業の方が忙しなってきてまして…。)

@fagai
Copy link

fagai commented Feb 29, 2020

こちらの状態ってどうなってるでしょうか?
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に登録するだけなので、影響度は低いと思います。

@rosylilly
Copy link
Member

@fagai 以前の回答と同様で、 woothee-php と同様にデータセットの PHP を生成する方式を実装しない理由がなく、また source-data は『特定の言語のための実装』を入れるべきでないと強く考えているため、このリポジトリに composer.json を追加することはありません。
ccomposer.json の更新で他言語実装のリリースが走ることは許容できないためです。

@fagai
Copy link

fagai commented Mar 1, 2020

なるほど。。。承知しました。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants