Composer: 動的パッケージのComposerリポジトリは、検索されたパッケージのパラメーターを受け取りませんか?

作成日 2016年08月16日  ·  3コメント  ·  ソース: composer/composer

私は_Composerプロキシサービス/リポジトリ_を構築中です。 ミニサービスのアイデアは、_WordPress_API応答からテーマまたはプラグインの言語/翻訳パッケージを動的に配信することです。 ルートは次のとおりです。

 https://api.wordpress.org/translations/plugins/1.0/?slug={slug}&version={version}

_Nodejs_-service自体は、 type:project composer.jsontype:project repositoryとして追加する必要があるプロキシにすぎません。 サービス自体は、(動的に生成された) packages.jsonファイルの一部としてproviders-urlキーを返します。

"providers-url" : "/" + request.params.scope + "/providers/%package%$%hash%.json"

例については、次のcomposer.jsonを参照してください。

{
    "name"              : "vendor/testproject",
    "type"              : "wordpress-project",
    "minimum-stability" : "dev",
    "repositories"      : [
        {
            "type" : "composer",
            "url"  : "https://{unique-ID}.ngrok.io/test"
        }
    ]
}

これまでのところ、 /endpoint/packages.jsonへのリクエストのみを表示できますが、パラメーターは表示されません。 理想的な世界では、Composerはrequiredパッケージをヘッダーまたはクエリパラメーターとして送信します。

私はすでに、利用可能なすべてのオプションを調べて(そしてテストして)、システムを_偽造_して、要求されたパッケージtype:{composer|vcs|…}取得しようとしました。 これを実現する方法はありますか? または、少なくとも、これを実装するためのPRを受け入れる_will_がありますか?その動作を有効にするための追加のフラグと一緒に?

ホスティングサービスに関する_Aノート:の組み合わせがあるかもしれませんnotify-batchrequest/requireを検索し、実際にフェッチされたリポジトリに関するいくつかの統計情報を収集するためのオプション。 このアプローチにより、「キャッシュする」パッケージをより適切にターゲットにできる可能性があります。_

Feature

最も参考になるコメント

現時点ではこれは不可能であり、しばらくはそうなるとは思えません。おそらくv2.0では、プールの要素をリファクタリングすると、これを実現できます。 とりあえず開いたままにしておきますが、息を止めないでください:)

全てのコメント3件

現時点ではこれは不可能であり、しばらくはそうなるとは思えません。おそらくv2.0では、プールの要素をリファクタリングすると、これを実現できます。 とりあえず開いたままにしておきますが、息を止めないでください:)

@alcoholラベルを今すぐ調整できると思います:)

ここでmetadata-url: "/p2/%package%.json"を実行でき、必要なすべてのパッケージが1つと呼ばれるため、v2メタデータ(詳細に興味がある場合はトラック#8248)で実行できる可能性があります。ただし、他のパッケージではなく、そのパッケージの名前のデータのみを返すことができるため、実際に役立つかどうかはわかりません。

ある程度その場でパッケージを生成できるので、プラグインにfoo/plugin-translations-enを要求させてから、常にパッケージを返して、インストール可能であることを確認することができます。翻訳が利用できない場合、何もインストールしない空のメタパッケージ?

このページは役に立ちましたか?
0 / 5 - 0 評価