Подтвердить что ты не робот

Как использовать подмодуль Git с библиотекой, загруженной композитором?

У меня есть приложение Zend Framework 2. Он содержит некоторый код библиотеки, содержащий бизнес-логику и некоторые другие утилиты, которые будут распространены для других приложений, которые будут созданы позже.

Мое намерение состоит в том, чтобы разделить его по проектам с помощью Composer. Вопрос в том, как мне сделать это правильно и оптимизировать разработку? Мне почти наверняка придется внести изменения и дополнения в библиотеку из другого проекта.

Я попытался настроить vendor/stuff как подмодуль git, содержащий необходимый пакет, и ссылаясь на него в основном composer.json, как это (ref):

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

Композитор не может загрузить его таким образом. Он жалуется, что пакет не может быть найден, по-видимому, потому, что он игнорирует тот факт, что URL-адрес является как локальным, так и относительным. Технически это не нужно; папка vendor/stuff была инициализирована отдельно через команды git subodule.

4b9b3361

ОТВЕТЫ

Ответ 1

К сожалению * Composer не поддерживает подмодули w20 > , поскольку основная цель Composer заключается в предоставлении аналогичной межпроектной функциональности зависимостей, и было бы бессмысленно пытаться реплицировать подмодули в Composer.

У меня та же проблема, которую вы пытаетесь решить, разработки библиотеки при одновременном развитии приложения, использующего эту библиотеку. Есть несколько способов решить эту проблему, просто используя композитор.

Сделать символическую ссылку для каталога библиотеки

Это самый быстрый и грязный способ сделать это. Просто выполните обновление для композитора, чтобы создать соответствующий каталог для библиотеки в каталоге ваших поставщиков, а затем замените его символической ссылкой из каталога, содержащего вашу библиотеку.

Очевидно, это не очень удобно, так как вы можете случайно перезаписать код, который вы, возможно, отредактировали, запустив обновление для композитора.

Использовать компоновщик предпочитает вариант источника

У композитора есть возможность загрузить исходный код с помощью Git clone (--prefer-src) вместо загрузки zipball (--prefer-dist), который является значением по умолчанию. Это позволяет редактировать исходный код внутри каталога поставщиков, а затем передавать его через Git.

например. Предположим, что у вас есть проект, который требуется среди других библиотек symfony/yaml, в который вы хотите исправить ошибку. Что вы можете сделать:

  • composer update - Это загрузит все зависимости проекта.

  • composer update symfony/yaml --prefer-source - теперь будет обновлен только каталог symfony/yaml в каталоге поставщиков.

  • Исправьте ошибку, а затем скопируйте ее через Git.

Использовать локальный репозиторий Composer

То, как я --- на самом деле... привык работать, когда я разрабатываю проект, и это требование в тандеме, заключается в том, чтобы использовать способность Composers установить явно установленный репозиторий для использования зависимостей. например если ваш код находится:

/projects/library/
/projects/project/

В файле композитора для вашего проекта добавьте запись репозитория:

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

Запуск composer update теперь будет искать записи Git в/projects/library/для разрешения любых зависимостей в библиотеке, предпочитающих те, которые перечислены в Packagist или другом репозитории.

Это означает, что когда вы хотите протестировать изменение в коде библиотеки, вам необходимо:

  • Зафиксируйте его, чтобы он имел запись Git.

  • Запустите Composer update в каталоге проекта, чтобы получить последнюю версию.

Но вам не нужно нажимать фиксацию на внешний репозиторий, что хорошо, поскольку это означает, что вы не нажимаете код, который может не работать, и это означает, что вы можете работать в автономном режиме, поскольку Git commit не требует интернет-соединение.

Несмотря на то, что это, по-видимому, лучший способ работы, это все еще опасно, поскольку слишком легко случайно проверить версию вашего композитора .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.json.

Просто клонируйте его с помощью Git

Вот как я сейчас работаю:

i) Обновление композитора в проекте ii) Зайдите в каталог поставщиков и удалите библиотеку, которую я хочу развивать одновременно. iii) Git клон из любого репо, в котором вы разрабатываете библиотеку, в соответствующий каталог поставщиков.

Composer понимает Git repos, поэтому не будет перезаписывать клонированный каталог Git (хотя, похоже, он немного запутался в редактировании библиотеки composer.json).

Выполнение клонирования Git самостоятельно, дает вам полный контроль над тем, что устанавливается, и позволяет вам устанавливать из репо, о котором не знает композитор, или немаркированную версию, без необходимости редактировать композитор .json в проекта.

Это ключевая особенность клонирования Git; не трогая композитор .json проекта, он полностью безопасен, без возможности проверки в composer.json, который был изменен для использования локальных/пользовательских репозиций.

  • Изменить - 6 сентября 2014 года

Проверка на файлы composer.json была затянута, и в файле больше нет записи "//": "LOCALHACK". Это еще одна причина, по которой ребята из Composer, не имеющие версии для проекта Composer, являются орехами.

* Я на самом деле думаю, что Git Submodules - это тупая, немая, немая реализация, чтобы "решить" сложную проблему таким образом, что только вызывает больше проблем в будущем, и поэтому композитор, не поддерживающий их, более "счастлив", чем "несчастный". Очевидно, что другие люди используют их и довольны ими, так что это только мое мнение, мужик, но если вы используете Composer, у вас не должно быть необходимости в подмодулях.

Ответ 2

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"
        }
    }
}

Обратите внимание, что строки образуют шестую строку внизу кода

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

Теперь обновите Composer

php composer.phar update

Таким образом, Composer также обновит файл автозагрузки, включая подмодуль.

Все сделано: теперь ваш подмодуль автозагружается композитором.

Надеюсь, это поможет.