web-dev-qa-db-ja.com

ComposerロードされたライブラリでGitサブモジュールを使用するにはどうすればよいですか？

Zend Framework 2アプリケーションがあります。ビジネスロジックを含むいくつかのライブラリコードと、後で作成される他のアプリケーションに共通する他のユーティリティが含まれています。

私の意図は、Composerを使用してプロジェクト間でそれを共有することです。問題は、これを適切に行い、開発を合理化するにはどうすればよいですか？ほぼ間違いなく、他のプロジェクト内から、ライブラリに変更や追加を加える必要があります。

設定してみましたvendor/stuff必要なパッケージを含むgitサブモジュールとして、プライマリで参照composer.jsonこのように （ref） ：

"repositories": [
    {
        "type": "git",
        "url": "vendor/stuff"
    }
],
"require": {
    "stuff/library": "master"
},

Composerは、この方法でそれをロードできません。これは、おそらくURLがローカルと相対の両方であるという事実を無視しているため、パッケージが見つからなかったと文句を言います。技術的には、その必要はありません。 vendor/stuffフォルダーは、gitサブモジュールコマンドによって個別に初期化されました。

composer-php
28
bcmcfc

残念ながら* ComposerはGitサブモジュールをサポートしていません。Composerの主な目的は、同様のプロジェクト間の依存関係機能を提供することであり、 Composerでサブモジュールを複製してみてください。

ライブラリを開発すると同時に、そのライブラリを使用するアプリケーションを開発するという、あなたが解決しようとしているのと同じ問題があります。 composerを使用するだけでその問題を解決する方法がいくつかあります。

ライブラリディレクトリのシンボリックリンクを作成する

これは、最も速くて汚い方法です。 composer updateを実行して、vendorsディレクトリにライブラリの適切なディレクトリを作成し、ライブラリを含むディレクトリからのシンボリックリンクに置き換えます。

composer updateを実行して編集した可能性のあるコードを誤って上書きしてしまう可能性があるため、これはすばらしいことではありません。

Composerソースの選択オプションを使用する

Composerには、デフォルトのジップボール（--prefer-src）をダウンロードするのではなく、Gitクローン（--prefer-dist）を介してソースをダウンロードするオプションがあります。これにより、vendorsディレクトリ内のソースコードを編集し、Gitを介してコミットできます。

例えばバグを修正したい他のライブラリsymfony/yamlを必要とするプロジェクトがあるとします。できることは次のとおりです。

  1. composer update-これにより、プロジェクトのすべての依存関係がダウンロードされます。

  2. composer update symfony/yaml --prefer-source-これにより、vendorsディレクトリのsymfony/yamlディレクトリのみが更新されます。

  3. バグを修正してから、gitを介してコミットします。

Composer local repositoryを使用します

プロジェクトを開発しているときに私が---実際に-作業に使用した方法とそれが並行して要件である方法は、依存関係を解決するために使用するリポジトリを明示的に設定するComposers機能を使用することです。例えばコードが次の場所にある場合：

/projects/library/
/projects/project/

プロジェクトのcomposerファイルに、リポジトリエントリを追加します。

"repositories": [
    {
        "type": "vcs",
        "url": "/projects/library/"
    }
]

composer updateを実行すると、/ projects/library /のGitエントリが参照され、Packagistまたは他のリポジトリにリストされている依存関係よりもライブラリの依存関係が優先して解決されます。

これは、ライブラリコードの変更をテストする場合は、次のことを行う必要があることを意味します。

  1. コミットして、Gitエントリーが含まれるようにします。

  2. プロジェクトディレクトリでComposer updateを実行して、最新バージョンを取得します。

ただし、コミットを外部リポジトリにプッシュする必要はありません。これは、機能しない可能性のあるコードをプッシュしていないことを意味し、Gitコミットはインターネット接続を必要としないため、オフラインで作業できることを意味します。

これは明らかに最良の作業方法ですが、ローカルディレクトリへの参照を含むcomposer.jsonのバージョンを誤ってチェックインするのは非常に簡単であり、明らかに他のすべての人にとってプロジェクトを中断させるため、依然として危険です。

これを回避するために、i）実際のcomposer.jsonファイルをバックアップするii）ローカルリポジトリを追加するiii）composer updateを実行するiv）実際のcomposer.jsonファイルを復元するいくつかの小さなスクリプトを作成しました。

localupdate.sh

cp -f composer.json composer.json.bak
php composerLocal.php
composer update
cp -f composer.json.bak composer.json

composerLocal.php

<?php

$srcFile = file_get_contents("composer.json");
$hackFile = file_get_contents("composer.local");
$finalString = str_replace('"LOCALHACK",', $hackFile, $srcFile);
file_put_contents("composer.json", $finalString);

?>

composer.local

"LOCALHACK",

"repositories": [
    {
        "type": "vcs",
        "url": "/projects/library1"
    },
    {
        "type": "vcs",
        "url": "/projects/library2"
    }   
],

次に、"//": "LOCALHACK",をプロジェクトのcomposer.jsonファイルのどこかに配置します。 localupdate.shを実行すると、ローカルリポジトリに対してcomposer更新が安全に行われ、不正なバージョンのcomposer.jsonがコミットされる可能性はありません。

Gitで自分で複製する

これは私が今働く傾向がある方法です：

i）Composerプロジェクトの更新ii）vendorsディレクトリに移動し、同時に開発するライブラリを削除します。 iii）ライブラリを開発しているリポジトリから、適切なベンダーディレクトリにGitクローンを作成します。

Composerはgit reposを理解しているため、gitのクローンディレクトリを上書きしません（ただし、ライブラリのcomposer.jsonの編集について少し混乱しているようです）。

自分でgit cloneを実行すると、インストールする内容を完全に制御でき、composerが認識していないリポジトリまたはタグなしバージョンから、編集することなくインストールできます。プロジェクトのcomposer.json。

これがgit cloneを自分で行う際の重要な機能です。プロジェクトのcomposer.jsonに触れないことで完全に安全になり、ローカル/カスタムリポジトリを使用するように変更されたcomposer.jsonをチェックインする可能性がなくなります。

  • 編集-2014年9月6日

Composer.jsonファイルの検証が強化され、ファイルに"//": "LOCALHACK"エントリを含めることができなくなりました。 Composer男がComposer=プロジェクトのバージョン管理を行っていないのは、骨の折れる理由です。

*実際には、Gitサブモジュールは、難しい問題を「解決」するだけの道のりであると思います。したがって、Composerそれらをサポートしないのが方法です「不幸」よりも「幸運」のほうが多いことは明らかです。明らかに他の人がそれらを使用していて満足しているので、それは私の意見ですが、Composerサブモジュールが必要です。

45
Danack

Composerには、ライブラリがPSR-x標準に準拠しているかどうかを確認するのに非常に役立つオートロードマッピング機能があります。同様の手順に従って、psr-x以外のライブラリを自動ロードすることもできます。

ここで参照： https://getcomposer.org/doc/04-schema.md#autoload

例を作ってみましょう（ライブラリがPSR-4標準に準拠していると仮定します）

サブモジュールをlib/your-private-git-repoフォルダーに複製したとします。

あなたがしなければならないすべてはあなたのcomposer.jsonファイルオートロードセクションに追加することです：

{
    "name": "YourNamespace/YourApplicationName",
    "description": "Describe your library",
    "license": "Your licen",
    "keywords": ["some","keywords"],
    "authors": [
        {
            "name": "Adamo Aerendir Crespi",
            "email": "[email protected]"
        }
    ],
    "require": {
        "joomla/framework": "*@stable"
    },
    "require-dev": {
        "phpunit/phpunit": "*@stable"
    },
    "autoload": {
        "psr-4": {
            "YourNamespace\\YourSubmodule\\": "lib/your-private-git-repo/src"
        }
    }
}

行がコードの下から6行目になることに注意してください

    "autoload": {
        "psr-4": {
            "YourNamespace\\YourSubmodule\\": "lib/your-private-git-repo/src"
        }
    }

次にComposerを更新します

php composer.phar update

このようにComposerはサブモジュールを含むオートロードファイルも更新します。

すべて完了：これで、サブモジュールがComposerによって自動ロードされます。

これがお役に立てば幸いです。

2
Aerendir

Gitサブモジュールを含むプロジェクトAがある場合、プロジェクトAからcomposer install/update..を呼び出すと、サブモジュールのすべてのcomposer依存関係が無視されます。

つまり、composer依存関係が含まれている場合は、gitサブモジュールを使用しないでください。

これは私がむしろそれをしたい方法です：

1）公式パッケージではない場合（フォークやプライベートリポジトリなど）、リポジトリをcomposer.jsonに追加します。

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/vendor_name/package_name.git"
    }
],

2）--prefere-sourceを含むパッケージを要求する：

composer require vendor_name/package_name --prefer-source

注：official/mangoを独自のリポジトリralf/mangoにフォークした場合、ralf/mangoのcomposer.jsonを指す必要がありますが、composerを呼び出しますrequire official/mango ..` docs で詳細を読むことができます。

これで、ベンダーやプッシュプルなどからファイルにアクセスできます。--prefere-sourceコマンドは、ベンダーファイル内のgit接続をすでにセットアップしています。

package/mangoではなくvendor/official/mangoのようなルートフォルダーからパッケージにアクセスする場合は、シンボリックリンクを設定できます。

0
Adam