Один общий поставщик с двумя проектами

Question

Один общий поставщик с двумя проектами

4

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

Итак, моя структура будет примерно такой:

project1/
project2/
shared_vendor/

Я читал об этом. Я изменил переменную загрузчика app/autoload.php:

$loader = require __DIR__.'/../vendor/autoload.php';

в

$loader = require __DIR__.'/../../vendor/autoload.php';

И я также изменил vendor-dir в моей composer.json на:

    "config": {
      "bin-dir": "bin",
      "vendor-dir": "vendor"
    },

в

    "config": {
      "bin-dir": "bin",
      "vendor-dir": "/../vendor"
    },

И после этого я получаю эту ошибку:

ClassNotFoundException in AppKernel.php line 20: Attempted to load 
class "CmsUserBundle" from namespace "Cms\UserBundle".
Did you forget a "use" statement for another namespace?

Что я делаю неправильно? Я забыл что-то изменить? Спасибо заранее.

r3m4k3 02 май 2015, в 10:28

Источник

0

CmsUserBundle живет в project_1/src/ или в shared_vendor/ ?
Wouter J 02 май 2015, в 08:52
0

Вам не хватает вручную редактировать конфигурацию автозагрузки композитора, которая загружает пространства имен проекта.
code-jaff 02 май 2015, в 09:16
0

Почему вы хотите это сделать? Наличие двух отдельных систем, использующих одного и того же поставщика, означает, что вы должны сохранить обе зависимости пакетов в одних и тех же версиях.
qooplmao 02 май 2015, в 09:26
0

@WouterJ Да, CmsUserBundle находится в проекте 1 / src.
r3m4k3 02 май 2015, в 11:18
0

@code-jaff code-jaff, что я должен точно изменить в композиторе?
r3m4k3 02 май 2015, в 11:20
0

@Qoop Я хочу иметь одного и того же поставщика для всех моих приложений. Я думаю о создании универсального пакета для библиотеки. И это не значит, что во всех проектах используются все библиотеки. Разве это не хорошее отношение?
r3m4k3 02 май 2015, в 11:28
0

Моя единственная проблема заключается в том, что каждое из ваших приложений связано с одной и той же версией пакетов. Это будет означать, что каждый раз, когда вы хотите обновить пакет (который также может обновлять любое количество других пакетов в каталоге), вы должны будете убедиться, что каждое из ваших приложений не было нарушено изменениями. Я просто представляю, что пытаться синхронизировать все зависимости ваших приложений было бы гораздо сложнее, чем выгодой.
qooplmao 02 май 2015, в 12:09
0

Общие библиотеки раньше были стандартом. Это не закончилось хорошо. С другой стороны, исправление этой проблемы даст вам представление о том, как работает процесс автозагрузки. Вам нужно исправить раздел psr-0 или 4 в файле composer.json. Но как только вы добьетесь успеха, вам, вероятно, придется отказаться от этого подхода.
Cerad 02 май 2015, в 13:09
0

Это действительно плохая идея!
Emii Khaos 02 май 2015, в 14:05
0

Это плохая идея
Fabien Warniez 02 май 2015, в 21:29
0

Хорошо, может быть, это плохая идея. Но я хочу сделать это, проверить это и затем решить, или это решение плохо для меня тоже.
r3m4k3 02 май 2015, в 21:38

Показать ещё 9 комментариев

Теги:

php

symfony

composer-php

autoload

vendor

2 ответа

0

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

Например:

cd /var/www/SiteA
composer install
# git clone new project into /var/www/SiteB
cd ../SiteB
# If vendor directory is already there, delete it: rm -rf vendor
# create symlink to Site A vendor directory
ln -s /var/www/SiteA/vendor

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

Abdou Tahiri 13 июль 2017, в 10:14

Ещё вопросы

CmsUserBundle живет в project_1/src/ или в shared_vendor/ ?
Вам не хватает вручную редактировать конфигурацию автозагрузки композитора, которая загружает пространства имен проекта.
Почему вы хотите это сделать? Наличие двух отдельных систем, использующих одного и того же поставщика, означает, что вы должны сохранить обе зависимости пакетов в одних и тех же версиях.
@WouterJ Да, CmsUserBundle находится в проекте 1 / src.
@code-jaff code-jaff, что я должен точно изменить в композиторе?
@Qoop Я хочу иметь одного и того же поставщика для всех моих приложений. Я думаю о создании универсального пакета для библиотеки. И это не значит, что во всех проектах используются все библиотеки. Разве это не хорошее отношение?
Моя единственная проблема заключается в том, что каждое из ваших приложений связано с одной и той же версией пакетов. Это будет означать, что каждый раз, когда вы хотите обновить пакет (который также может обновлять любое количество других пакетов в каталоге), вы должны будете убедиться, что каждое из ваших приложений не было нарушено изменениями. Я просто представляю, что пытаться синхронизировать все зависимости ваших приложений было бы гораздо сложнее, чем выгодой.
Общие библиотеки раньше были стандартом. Это не закончилось хорошо. С другой стороны, исправление этой проблемы даст вам представление о том, как работает процесс автозагрузки. Вам нужно исправить раздел psr-0 или 4 в файле composer.json. Но как только вы добьетесь успеха, вам, вероятно, придется отказаться от этого подхода.
Хорошо, может быть, это плохая идея. Но я хочу сделать это, проверить это и затем решить, или это решение плохо для меня тоже.

Jens A. Koch · Accepted Answer · 2015-05-04T23-36-00.000Z

Композитор работает на основе каждого проекта.

Один проект - одна папка поставщика. Нет, два проекта и одна "общая" папка поставщика.

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

В любом случае...

если вам нравится настройка "shared vendor folder", я бы предложил создать что-то вроде "обертки" или "супер" проекта, который действует как контейнерный репозиторий для двух других проектов. Проект оболочки будет содержать файл composer.json с требованиями для обоих (!) Проектов. Это означает, что вы работаете с одним и тем же набором зависимостей в обоих подпроектах.

Это позволяет определить требования для обоих подпроектов (cms и shop) в "обертке" репо. В принципе, я предлагаю следующую структуру:

|-container-project
  +-CMS
    |-src
    +-tests
  +-Shop
    |-src
    +-tests
  +-vendors      // contains dependencies for both projects (CMS + Shop)
|-composer.json  // define requirements for both projects

Эта настройка позволяет вводить файлы composer.json для подпроектов. Вам просто нужно передать требования из файла composer.json суперпроекта в файл composer.json подпроекта.

Теперь также можно настроить поведение автозагрузок подпроектов, зарегистрировав автозагрузчики в определенном порядке.

Хорошо, спасибо за объяснение. Я буду использовать одного поставщика для одного проекта, как вы все написали. :)