読者です 読者をやめる 読者になる 読者になる

peketaminの日記

その辺のプログラマーです。うーむ…。

(感想) composerのローカルパッケージ自作を試みていた

php

雑なあらまし

  • 友人との実験サイト作成で使うために、コア機能となる自作ライブラリをプロトタイピングしていた。
  • 外部サービスアクセス用のいろんな認証キーを含んだままガシガシ書いていた。
  • (実験だし〜軽くざっくり始めていけばいいっしょ〜) という程度の認識だった。

そのライブラリが大体出来たら、Laravelとかのフレームワークと一緒に使おうと思っていた。

が。

自作ライブラリを別作者の外部フレームワークから独立して改修 (保守) していくには、 require_once() (include ()) じゃ、すごい面倒が雪だるまじゃん!

課題 → ライブラリをアップデートした場合にフレームワーク内の同ライブラリどうするのか

  • git のサブモジュール管理だと経験的に色々辛い (本番アップとかも)
  • コピーしてrequire_once() だと似たようなものが複数箇所に分散してしまうことで、再利用性が下がる (他のプロジェクトでも流用しよう!となった時に、またコピーしてたら、どれが最新版か分からなくなって保守しきれない)
  • シンボリックリンクでうんぬん→開発サーバーと本番サーバーが存在する時点で、どっちがオリジナルなのよ?どっちが最新なのよ?ってなっていっちゃう。ステージングとかテストサーバーも増えると、ほら、レガシーな感じで暖かみが出てくる。

やっぱり行き着くところは同じで、CPANやGemやpipとかそういうのに相当する composer がラクそうですよね…となった。

使うのはいいけど、自作するのは流儀を覚えるのが面倒で避けてた。(その辺のエンジニアあるある)

composerとは、php のパッケージ管理システムのアレ。 → Composer

composer.json に、メインシステムに必要な依存ライブラリを書いた後、

  • php composer.phar install

とか

  • php composer.phar update

とかするやつ。

参照したサイト

メモ

  • .gitignore に /vendor を入れておこう
  • PSR-4 の方が PSR-0 に比べて、ディレクトリ構造が冗長になりにくくて、よさ気
  • 自作ライブラリを書いたら、そのディレクトリにおいて、git でコミットして、更にcomposer install/update もする感じ? (gitでコミットだけでいいのかも)
  • 本体は src/ に置き、テストは tests/ に置く決まり
  • 通信が絡むテストは…勉強不足です。
  • 1つのphpファイルに2-3のクラスを書いてたせいか、そのままだとサンプルプログラムにautoload.phpを取り込んで動かそうとしても動かなくて composer.json に classmap を指定して、再度、composer update したらサンプルプログラムが動いた。1ファイル1クラスの原則だったかどうかは、まだちゃんと各資料を見直してない

感想

  • 土台になる部分を作るときは、あんまり雑に進めていくと後で帳尻合わせが増える
  • 選定と検討にあまりに時間がかかっている場合、とりあえず手を動かして失敗をしていく方が「マシ」→悪いものと悪いものを比較した場合の話。
  • いったん、composerパッケージにしてしまえば、composer対応のフレームワークなら他のフレームワークでも大体同じ感じで使えし、やっぱりgitのサブモジュールよりラク。
  • パッケージ検索か依存性解決か、ちょいちょい composer install/update が遅い…(重い?)

新宿bookathon行って主催者さんからOSSコミッターとしてのお話を少し聞かせて頂いて、 ちょっと元気を貰ったので、家プログラミングが少し捗った。