続き的なもの。 この前、「うまくhackしたらインストール早くなるの？」という話を書いて見た。
魅力あるし、単純に勉強としてcomposerの挙動を知るぞ！！は面白そうなのだけど、「現実問題としてほしいかい？」がある。
あー、まぁ、ほしいけど、「何も知らないところからcomposerのプラグインを書く(大変そう)」事のコストと、「今直面している問題の所在と大きさは？」のバランス。
で、結論として、「意外と困ってないかもな」となった。
この辺りは、職場での開発・デプロイフローがどうなっているか？という話次第だった。*1
という現状。
で、「遅くて困る」かどうかは
- composerはなぜ遅いのか、何をクリアすれば遅さが気にならなくなるのか
- composerの遅さが気にならなくなるのはどんな場面か
- 開発時、デプロイ時に問題となるか(回避できるか)
という複合だと思う
なんで遅いの
については、色々ありそうだ・・ ただ今回の話は、「各パッケージを並列DLできたら解消し得る問題」に絞りたい。
そうなると、「DLの遅さ」だ。*2
で、これに関しては標準のキャッシュを活かせればほぼ解決する。・・全てではないが、まぁかなり嬉しいレベルで軽減する。
いつ問題になるの
- 新規にinstallするとき
- .lockを利用してinstallするとき
- requireするとき
- updateするとき
が、「何かパッケージを落としてくるとき」なので、影響を受ける。
余談だが、ただし2に関しては「依存状態の解消を行う」ような処理は完了している！という状況といって差し支えないと思う。そのため、コンフリクトする可能性を前提として排除できるからパラで落として来て問題なくない？というのが前に書いた内容だった。
開発時やデプロイ時に問題となるか
「遅さやばい」となのはキャッシュがきかない時で、「日常的に行う」のは2になると思う。
もっというと、ローカルでの開発において(ブランチの切り替えやdocker imageのビルドに比べたら)composer installなんて「やらないで済むならやらないで済ませたい(必然性が低い)」ものではないか。
なので、「問題となるか否か」は「キャッシュがきけば問題ない」から「キャッシュが効く場面を最大化できれば実質解決する」はず。
デプロイについて
travis-ci上でdocker imageをビルドしているという話をしました。
で、ci上にキャッシュを残す機能がある。.travis.ymlに caches/directoriesを指定してあげると、そのディレクトリがピルドプロセスをまたいで共有されるようになるので、$COMPOSER_HOME/cache を対象にしてあげれば良い。そうすることで、「いちいちpackagis→githubからダウンロードしてこないで済む」ことになる。もちろんvendorディレクトリごとキャッシュしたりもできるし。
これを利用して、CMD等でコンテナに作用するのではなく、ビルド時にcomposer installをするよな形にして、「installは1回だけに、しかもその1回を高速で完了させる」という要望は叶えられる
localでの開発時
これも「毎回クリーンインストールはしないよね・・・」という話は大きい。
基本的な戦略は同じで、「キャッシュを使いまわせるようにする」なのだが、imageに含めるよりかはマウントする形でホストからコンテナに渡す方が自然な感じがする。まぁ共有すゆのは「キャッシュじゃなくてvendor自体」になると思うので、composer.lockからのinstallをかけところで所有済みパッケージとのdiffがない！となり、そもそもキャッシュを参照しにいかないで済む場面が大半な気はする。
ということで
自分の今触れている状況においては、composer install自体はそんなに問題になっていなさそうだなーというかんそ
