web-dev-qa-db-ja.com

composer install？

これら2つのパッケージをインストールしたい：

  • 「anahkiasen/former」：「dev-master」
  • 「vespakoen/menu」：「dev-master」

しかしcomposerは、それぞれがこのパッケージの異なるバージョンに依存することを示しています。

  • 「anahkiasen/html-object」：「dev-master」
  • 「anahkiasen/html-object」：「1.1.2」

問題1

- Installation request for anahkiasen/former dev-master -> satisfiable by anahkiasen/former[dev-master].
- Can only install one of: anahkiasen/html-object[dev-master, 1.1.2].
- vespakoen/menu dev-master requires anahkiasen/html-object 1.1.2 -> satisfiable by anahkiasen/html-object[1.1.2].
- anahkiasen/former dev-master requires anahkiasen/html-object dev-master -> satisfiable by anahkiasen/html-object[dev-master].
- Installation request for vespakoen/menu dev-master -> satisfiable by vespakoen/menu[dev-master].

どうすれば解決できますか？

conflictcomposer-php
33
cawecoy

ここでの基本的な問題は、タグ付きバージョンの代わりにブランチ（dev-master）を使用することです。ブランチを使用すると、問題が発生する可能性が非常に高くなります。 StackoverflowのComposerの質問を見ていて、パッケージに関する問題を報告するたびに、99％の開発ブランチと "minimum-stability：dev"を使用しています。

何が起こっていますか？これらのパッケージを初めてインストールすることを前提としています。 Composerはインストールしませんが、パッケージを更新します。そうしないと、すべてのバージョン要件を満たすことができるバージョンのワーキングセットがcomposer.lockに記録されます。

依存関係の状況は次のとおりです。2つのパッケージは3番目のパッケージに依存していますが、これら2つのパッケージには互換性のないバージョンが必要です。

修正できますか？ローカルのcomposer.jsonファイルには、3番目のパッケージのインストールを許可するツールが1つだけあります。 インラインバージョンエイリアス を使用してインストールします。

"require": {
    "anahkiasen/former": "dev-master",
    "vespakoen/menu": "dev-master",
    "anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}

Dev-masterブランチをインストールし、バージョン1.1.2のように宣言することにより、Composerは両方のパッケージの依存関係を解決できます。

これに伴う問題は、3つ目のバージョンで、4つ目のパッケージに応じて3つのパッケージがある瞬間に失敗することです。

正しいことは、すべての開発ブランチがcomposer.jsonにブランチエイリアス宣言を含めることです。これにより、Composerはdev-masterブランチが実際にバージョンと同等であることを検出できますここで役立ったかもしれない1.1.x（ただし、パッケージに特定のバージョン番号が明示的に必要な場合はそうではありません-1.1.xは1.1.2ではありません）ブランチエイリアスの追加はまだ良いことであり、実行すべきです。 composer.jsonのこのハードコーディングされたバージョンエイリアスの継続的なメンテナンスを避けるため、名前にその.xバージョンを含むブランチでそのバージョンを開発できます（つまり、「v1.1.x」または「1.1.x」 Composerにより開発の安定性に上記バージョンを含める）によって検出されます。

最後の段落で説明した問題は、パッケージが特定のバージョン番号を明示的に必要とすることに注意してください。このアプローチでは、このようなパッケージが必要な場合、その依存パッケージの別のバージョンを自分で使用したり、別のパッケージで使用したりすることはできません。 1つのバージョンのみが必要な場合もありますが、より良い解決策はバージョン範囲を要求することです。

私の個人的な好みは、1.0より大きいバージョンにキャレット演算子を使用することです。^1.1.7は最小バージョンとして1.1.7を必要としますが、互換性のない変更があると考えられるバージョン2.0.0には更新しません。パッケージがセマンティックバージョニングに従って新しいバージョンで慎重にタグ付けされている場合、これは魅力のように機能します。互換性のない変更に驚かないことはありません（もちろん、人間の性質が干渉する場合を除きますが、ソフトウェアが破損した場合、この障害を検出して更新をロールバックできるはずです）。

バージョンが1.0未満の場合、キャレット演算子はチルダ演算子とは異なる動作をすることに注意してください- 詳細はマニュアルを参照してください 。セマンティックバージョニングが0.xの範囲で互換性のない更新を許可している場合でも、「互換性のある」機能更新を取得するために、0.xのタグが付けられた私の制御下のパッケージにはチルダを好みます。

ただし、セマンティックバージョニングがなくても、1.1.*（今後のすべてのバグ修正リリースに更新される）または>=1.1.2,<1.2.5を定義するなど、バージョン番号の不正確さが少しでも役立ちます。

最悪の事態は「dev-master」を必要とすることです。これは確かに非常に不正確ですが（更新する時間に応じてブランチ内のコミットの可能性を解決します）、問題は、どのコミットを正確に知らない限り「dev-master」の前のバージョンに戻れないことです。必要なIDを追加し、この要件をcomposer.jsonに追加します。ただし、上記とまったく同じ状況で、正確なバージョンが必要です（gitタグは、コミットIDの名前付きエイリアスにすぎません）。

58
Sven