sim3x: да, это понятно, но тем не менее каждый раз их накатывать обратно та еще морока. Выше предложили решение, делать файлы примеров настроен для разных сред различными файлами, типа .env.example-dev и .env.example-prod. Но что, если есть различия в коде и файлах, которые постоянные. Те же тесты, например, которые только в локальном хотелось бы оставить, и при этом хранить их в репозитории, конечно.
Сергей: Отличное решение, согласен. Но только лишь для файлов настроек, вообще же между проектами в принципе могут быть различия, о чем я в примечании написал, в том числе в коде. Как пример - постоянно присутствие различных dev-инструментов - тех же тестов. Как быть с ними?
Dmitriy Ronzhin: тогда вам стоит уточнить это в своем вопросе, так как тест предполагает, что вы только стартуете и хотите протестировать именно продажи, другими словами - вы решили попробовать реализовывать новый для вас товар и хотите прощупать рынок. Сейчас же у вас, если я верно понял, товары уже протестированы, то есть тест будет не продаж, а новых возможностей магазина.
Это чисто терминология, но тем не менее, правильно мыслить - значить правильно принимать решения :-) Так вот, если вам нужен именно переезд вашего магазина на некую платформу с автоматизацией различных бизнес-процессов, то тем не менее вам нужно создать некий список требований к нему - какими службами доставки пользуетесь и для чего у них есть интеграции, какие платежные сервисы (и тут спрашивать нужно не сообщество, а самих себя, так как там разные фин. условия), какие у вас есть поставщики и в каком формате они предоставляют свои данные, и тд и тп.
Дмитрий: согласен, но REST API такая вещь, которая, как по мне, меняется очень редко, при этом угроз безопасности, в сравнении с полноценным вебсайтом, на порядок меньше. В итоге на поддержку можно и забить, на мой взгляд, лишь бы текущим требованиям удовлетворял. Если только это не какой-то серьезный будет сервер, который прям корпоративный дальше некуда.
Да, спасибо за ответ, и что поняли меня с первого раза, надеюсь :)
По поводу инструкции я уже все почитал, собственно это свой мелкий проектик, так что проблем нет.
Что же касается сути вопроса, то, возможно, я вас не понимаю. Моя идея была в том, что на каждом уровне, project, package and subpackeges есть свой собственный composer.json, и была надежда, что они как-то иерархично обрабатываются, в том смысле, что если я введу на уровне project команду compose update package, но такая конструкция, задающая обновление одного единственного пакета для первого (или второго, если угодно) уровня, не задаст такое же поведение на уровне втором (или на третьем, опять же).
Давид Габриелян: что именно непонятно? Есть project:1.0, у него есть в зависимостях package:1.0, у которого в зависимостях есть subpackage:1.0. Мы хотим обновить package до 2.0. При этом в этой его версии в его зависимостях subpackage уже версии 2.0
Что делаем? В composer.json нашего project в зависимостях пишем изменяем "package": "1.0" на "package": "2.0", после чего выполняем composer update package. Видим лог, который приведен в посте. Что должно было произойти на мой взгляд? Что package должен был обновиться, заодно обновив все пакеты, от которых он зависим. Что произошло на самом деле? Composer посчитал, что мы хотим обновить только package, без его пакетов в зависимостях.
Как решить? Не выпендриваться и использовать composer update, без указания, какой там пакет мы хотим обновить, если только мы не его один действительно хотим обновить.
Почему я решил использовать composer update package? Потому что не хотел, чтобы вообще все зависимости project обновлялись - ну например я в composer.json сразу у всех пакетов версии изменил, требуемых к обновлению, ну или не помнил, что обновлялось а что нет, не важно, вопрос не в этом. Так вот, требовалось обновить только package, и предполагалось, что если мы находимся на уровне project, и указываем composer'у обновить только какую-либо одну из его зависимостей, то на уровне package все его subpackage(1-N) все равно будут автоматически обновлены.
Но это оказалось не так. Логика своя в этом есть, но честно говоря, хотелось бы, чтобы иерархия в таких вещах соблюдалась.
JhaoDa: ник был придуман 16 лет назад специально для тех, кто ведется на ники. Добро пожаловать в клуб.
legolas4444: а не проще доустановить потом нехватающие пакеты отдельно к нему? В любом случае, он заточен именно на использование его в том числе в виде сервера REST API. Но можно было бы посмотреть на другие микрофреймворки, этот ответ уже пишу скорее для будущих читателей, чем для вас. Например, Phalcon. Он, кстати, будет в разы быстрее laravel / lumen, так как является скомпилированным заранее, и не интерпретируется каждый раз при обращении к нему. Если хотите, могу вынести это как отдельный ответ для вашего вопроса.
В общем, вы в целом угадали, что я имел ввиду, но так как чтобы правильно задать вопрос, надо знать половину ответа, правильно задать я его тогда и не смог. В любом случае, спасибо за ответ.
Вроде бы, phpldapadmin позволяет администировать через web-интерфейс ldap, верно, а не просто группы и пользователей? Поправьте, если я неправ. Но вообще штука полезная, так или иначе надо ее запомнить.
xmoonlight: ну вот думалось, что кто-то сделал уже. Руление - ну, типичные задачи с пользователями и группами, для начала чтобы даже просто удобно смотреть было все это.
xmoonlight: да я собственно и не совсем то искал, интересовала либо консольная утилита, либо некий веб-скрипт чисто для руления пользователями и группами, с визуальным интерфейсом.
Возможно, мы о разном говорим. Во-первых, у меня Lite версии 4.4. Я не могу даже группы в нем разрулить. Понятно, что можно все делать через консоль, но честно говоря нет ни времени ни желания для этого каждый раз.
