ここでぼやいても誰にも伝わらない気がするけど、一旦吐き出しておきます。 事の経緯 私は https://packagist.org のミラーサイト packagist.jp を運営しています。 スクレイピングのプログラムがバグっていて、1ヶ月に一度ぐらい古くなったファイルを掃除して回る定期作業があるのですが、その中で妙にlaravel関連のパッケージ情報が巨大であることに気づきました。 例えば、私のMacのローカルキャッシュに残っているパッケージ情報をファイルサイズでsortすると、上位は全てlaravel関連のものになります。これらはpackagist.jpの中にミラーリングされているファイルと全く同じものです。 1971473 p-provider-2016-01.json 2058474 p-provider-2016-04.json 3687200 provider-illumin
Composerやmonologの作者である@seldaekが来日するということで、2016年7月22日にPHP勉強会の番外編が開催されました。 PHP勉強会＠東京〜番外編〜 みなさまお疲れ様でした！ #composer #php #phpstudy #eventdots pic.twitter.com/wvKHgpDNGp — しめじ (@TAKA_0411) 2016年7月22日 動画 @seldaek の発表 発表資料はこちら: Composer in 2016 #phpstudy #eventdots pic.twitter.com/h4UeksQGvJ — Hiraku (@Hiraku) 2016年7月22日 Composerを使い込んでないとわからない内容もあったと思うので、勝手に補足解説しようと思います。 composerのエコシステムについて Composerの中央リポジ
Composer Versions vs VCS Versions VCS Tags and Branches Tags Branches Stabilities Minimum Stability Writing Version Constraints Exact Version Constraint Version Range Hyphenated Version Range (-) Wildcard Version Range (.*) Next Significant Release Operators Tilde Version Range (~) Caret Version Range (^) Stability Constraints Summary Testing Version Constraints Versions and constraints# Composer
Composerのリポジトリは簡単な認証であれば設定できるようになっている。基本的に$(composer config -g cache-dir)/auth.jsonに記載していくが、configコマンドでも設定が可能。 すべてドメインごとに設定できる。 Basic認証 なんかconfigコマンドに渡すhttp-basic.という部分がドメインの一部っぽく見えるが関係なくて、http-basic.まではJSON記法、それ以降がドメインを指す。(http-basic[example.com]みたいな記法だったら分かりやすかったのに。。) たとえばexample.comに対してユーザー名：aribaba パスワード：opensesameが必要だったとしたらこんな感じ。
composerが遅くてお嘆きの日本のPHPerの皆さんこんにちは。 表題の通り、追加インストールするだけでcomposerが速くなるプラグインを作りました。 # インストール $ composer global require hirak/prestissimo # アンインストール $ composer global remove hirak/prestissimo インストールした状態でlaravel/laravelをcreate-projectすると、26秒とかでダウンロード完了しました。Laravelは50個ぐらい依存パッケージがあり、同じ環境で普通にインストールすると5分ぐらいは最低かかるので、10倍以上速くなってます。 2016/1/13(水)にPHPBLT#2というイベントがあり、その中で同じデモをしてきました。 Composer並列化プラグイン #phpblt from
サーバーサイドエンジニアの@Hirakuです。 2016年7月16日(土)、 PHPカンファレンス関西2016 にて基調講演をしてきましたので、その報告と補足をします。 トーク動画は後日公開されると聞いていますので、口頭で補足した内容などはそちらをご期待ください。 内容について 講演内容は今年2月に公開した記事 光遅い問題を克服してcomposerを10倍速くした話 – Mercari Engineering Blog をもう少し詳しく解説したものです。 基調講演ということだったので、Composer自体の細かい話をするよりも、なぜこんなことに時間を費やしてきたのか、自分より若いエンジニアに何か伝えるものがないか、というようなことを考えて、エモ全開の内容になりました。 改善活動だけを話すとComposerを貶す内容になってしまいます。詳しい事情も知らない人にDISの口実を与えるのも嫌だった
composer-pluginの一種なんだけど、ちょっと面白いなと思った。 インストール(グローバルでもいいし、パッケージローカルでもOK)すると、composerのサブコマンドに、qa:から始まるものが色々生える。 webysther/composer-plugin-qa 自体は、特に何かをrequireしているわけではなく、このサブコマンドを生やすという機能単体で実装されている。 composer qa:testがPHPUnitに対応していて、ローカルにインストールされた vendor/bin/phpunit と同等の意味になる。 他にもphpcbf, phpcsなどのツールも、composerのサブコマンドから叩ける用にしてくれる。 vendor/bin/phpunitの代替手段 - Qiita scriptsで頑張ってcomposer testなどのサブコマンドを生やしている人も多
昨今のPHPを使った開発の現場では、パッケージ（プロジェクトで利用するライブラリ）の依存管理をComposerに任せて、packagistに登録されたOSSのパッケージや、Satis等で構築したプライベートなComposerリポジトリに登録した自社のパッケージを組み合わせて開発するスタイルになっていると思います。 このような開発で、自社のパッケージも積極的に作っていく場合、どうしても、1つのアプリケーションを開発しながら同時に複数のライブラリパッケージを修正するといったことが必要になってきます。 Composerを使うと、開発対象のアプリケーションの依存パッケージは、プロジェクトのvendorディレクトリ配下にすべて保存され、composer updateコマンドで更新などが行えます。複数のパッケージの開発を同時に進める場合は、基本的にルートとなる1つのアプリケーション/パッケージのプロジ
この記事を書くにあたって、これまで何度か読んだことのあったComposerのソースを再度読み直して理解しようとしてみました。ですが、Composerのソースってなんだか難しくて、分かった！という感触はまだまだつかめていません。Composerのソースがひどくスパゲティだ！なんてことはないのですが。 おそらくこれはソースの問題というよりも、私自身の、取り扱っている問題そのものに対する理解が浅いからなのだろうと、現時点では結論づけています。ひとまずComposerに登場する最も主要な構成要素を、図にまとめておきます。 ところで、前回の記事では、Composerがvendorディレクトリ配下のパッケージ内の状態をどのように管理しているのかを簡単に解説しました。 今回は、複数のパッケージを同時に開発する場合の流れを例にして解説します。 注：複数のパッケージを開発するときに、必ずこの流れでないといけ
あんまり知られてないけど有用な composer の機能 ※ 下記の内容はすべて公式マニュアルに書かれています ※ 社内向けに書いたので若干整合性が怪しい create-project 知られていないどころか超有名な機能ですが、尺稼ぎで create-project から。 フレームワークをいじってると 下記のコマンドでインストールします composer create-project symfony/framework-standard-edition my_project_name のような文言によく出くわします。 これがなにしてるかは http://qiita.com/DQNEO/items/74f4bb8fe447e4582a97 が詳しい。 要するに git で引っ張ってきてその中で composer install してるだけのようです。 使うことはあまりないと思うけど、覚えて
PHPとComposerで先日composer/composerのdev-masterに依存したプログラムを作っていたら、composer installのときに以下のようなエラーがでてインストールできない問題にぶちあたりました。 Your requirements could not be resolved to an installable set of packages. Problem 1 - kohkimakimoto/altax v3.0.6 requires composer/composer dev-master -> no matching package found. ... 解決方法はcomposer.jsonに"minimum-stability": "dev"と"prefer-stable": trueを指定するか、対象のパッケージに"composer/compo
対象読者 この記事は主にcomposerのパッケージを開発しているパッケージメンテナーのための記事です。 低いバージョンの依存テストの必要性 composerで作成したパッケージを他のパッケージから利用する場合composer.lockは無視されます。 this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project. 通常与えられた条件の最新のバージョンがインストールされます。テストは最新の依存だけをテストすることになり。^や~で指定した最低のバージョンのテストは行われません。 これが問題になるのは、他のパッケージが特定のパッケージの低いバージョンのものに依存していて、また他のパッケージではその高いバージョンのみにある
はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
これは結構大きいPHPのプロジェクトに composer を導入する機会があったので、そのときに考えてたことや行ったこと、使い方などをメモするために書いた。 モチベーション 私達は PHP のパッケージの管理を管理する際は pear と git submodule を利用していた。これらのやり方は意外と長続きした。これらにはついて様々な問題を抱えており、ついに限界がきてしまった。 pear pear でパッケージを導入するには root 権限が必要なので、毎回インフラチームに導入を依頼するのが必要があった。 pear で導入されたパッケージについてバージョンを上げようとすると、全APサーバーで更新をかける必要があった。 これらの点から面倒だったのと、気軽に変更できないので、不要になったものも削除されることなく、放置されるのが問題だった git submodule こちらは pear とは異
最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。 これまで聞いた話をまとめると、大きく分けて、以下の２パターンになります。どちらの方法を取っているか教えて下さい 😀 0. 前提 前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。 PHP コードは、Git などの VCS で管理する。 composer.json, composer.lock は、VCS で管理する。 composer.phar, vendor/ は、VCS で管理しない。 また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。 1. 本番サーバで実行 本番PHPサーバ上で compo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
