1

作曲家のセットアップでは、 と が必要vendor/package-Aですvendor/package-B。

パッケージ B はパッケージ A に基づいて構築されており、composer.json で要件として A が定義されています。

基本パッケージ A を直接インストールすると問題なく動作します。その他の要件は Packagist から解決され、パッケージ自体はプライベート リポジトリから正しくプルされます。

ただし、パッケージ B のみをインストールすると (要件によりパッケージ A もプルする必要があります)、次のエラーが発生します。

Your requirements could not be resolved to an installable set of packages.

Problem 1
  - Installation request for vendor/package-B dev-master@dev -> satisfiable by vendor/package-B[dev-master].
  - vendor/package-B dev-master requires vendor/package-A dev-master@dev -> no matching package found.

どちらのパッケージにもタグ付きリリースはなく、dev-master バージョンで動作します。

私が見落としているものはありますか？

編集

ソリューションに興味がある人のために、これは以下の選択した回答から学んだことの要約です。

基本的に、dev-master の深い依存関係をインストールする方法は 3 つあります。おすすめ順：

  1. すべてのリリースにタグを付け、どこでも dev-master の代わりにタグ付きのバージョン制約を使用します。（私は実際にこれをやった！）

  2. アプリケーションので、dev で必要な対応するサブ依存関係composer.jsonのフラグを使用して、require キーを追加します。@dev

    {
    "require": {
        "vendor/package-B": "dev-master",
        "vendor/package-A": "@dev"
    }
}

    このようにして、基本的に、dev として使用される特定のサブ依存関係をホワイトリストに登録します。

  3. アプリケーションのに、次のように キーとキーをcomposer.json追加します。minimum-stabilityprefer-stable

    {
    "minimum-stability": "dev",
    "prefer-stable" : true
}

    この最後の方法では、安定性の制約を dev に下げますが、安定したバージョンが利用可能な場合は、代わりにそれを優先するようにも設定します。ほとんどの場合、これで目的の動作が生成されますが、奇妙な動作になる場合もあります。

4

1 に答える 1

2

これは、安定性解決の問題です。

この状況の最善の解決策は、リリースのタグ付けを開始することです。

を定義できます"minmum-stability":"dev"。

下限を設定し、すべてのパッケージに対して「dev」パッケージを許可します。

を明示的に定義しdev-master@devました。これが本当に必要かどうかはわかりません。

これはあなたの状況を説明しています: https://igor.io/2013/02/07/composer-stability-flags.html

于 2015-03-25T16:53:28.920 に答える