Почему при перезапуске phpStorm (Windows) слетает composer?

#phpstorm #composer

При перезапуске phpStorm и открытии проекта перестает работать composer. Приходится
каждый раз заново открывать Tools/Composer/Init composer и указывать путь к php.exe
и composer.path. Данная проблема наблюдается при открытии лишь некоторых проектов.
Подскажите, в чем может быть проблема? 

phpStorm 10.0.3
    

Ответы

Ответ 1

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


Нужно чтоб был настроен интерпретатор PHP: Languages & Frameworks/PHP Interpreter
(выбрать исполняемый файл PHP php.exe) чуть выше PHP language level должен соответствовать
версии выбранного интерпретатора.
Собственно, настроить сам композер. Для этого:


он должен быть доступен в проекте: либо установлен глобально, либо в папке проекта
должен находиться файл composer.phar. Для глобальной настройки убедитесь, что команда
composer в консоли выдает список команд.
указать путь к используемому файлу composer.phar либо глобально доступному, либо
локально установленном в проекте.



Возможные проблемы:


Файл композера недоступен для вашего проекта. Убедитесь, что в папке вашего проекта
доступна команда composer для глобальной настройки или php composer.phar для локальной.
В настройках PhpStorm указан НЕ тот файл composer.phar, который доступен в вашем
проекте. 
PhpStorm хранит локальные настройки проекта в папке .idea. Убедитесь, что вы не перезаписываете,
не удаляете и не изменяете эту папку для вашего проекта при перезагрузке. Убедитесь
так же, что путь к проекту указан правильно и не был изменен при перезагрузке.


В конце хочется сказать, что вы очень ограничиваете ответы на ваш вопрос изначально
сузив их до той части, которая уже не принесла вам положительного результата. Лучше
бы вы спросили, как реализовать именно то, что вам нужно. Например, как установить
новый пакет в проект при помощи композера? Возможно, и скорее всего, есть более простые
пути решения вашей проблемы, о которых вы просто не знаете.


Ответ 2

Это "особенность" настройки composer через "Tools/Composer/Init composer". Настройте
composer в проекте вручную.


Откройте настройки "File/Settings" 
Перейдите в раздел "Languages &
Frameworks/PHP"
Выберите интерпретатор php
Перейдите в раздел "Languages &
Frameworks/PHP/Composer"
Укажите путь до composer.phar и comopser.json

Запустить PHPUnit тесты из docker контейнера через PhpStorm

#php #phpstorm #composer #docker #phpunit

Что есть:


Docker-контейнер с PHP и набором юнит-тестов. Можно запустить контейнер, и внутри
через консоль запускать любые тесты - phpunit /test/test_1.php
хостовая машина с установленным PhpStorm 9
папка с проектом, где лежат в том числе юнит-тесты. Эта папка залинкована в докер-контейнер.


Проблема:

PhpStorm удобно менеджерит тесты, и позволяет запускать локальные или удаленные тесты
(посредством SSH). Но с докером работать не умеет, не получается обьяснить IDE как
запускать тесты, лежащие в докере.

Что нужно:

Как поднастроить докер или PhpStorm, чтобы через GUI можно было запускать тесты.

Дополнения:


по ssh работает сейчас, но хотелось бы обойтись без него.
пробовал создать bash-скрипт, который проксирует все запросы в контейнер. Вот такой
скрипт docker run --rm php:cli php $@. Таким образом начинает работать команда php
-v запущенная с хостовой машины. Но тесты используют аргументы файлы. Усложнил баш-скрипт:

#!/bin/sh

args=''
for arg
do
   if [ -f $arg ]; then
        arg=/mnt$( realpath $arg )
   fi
   args="$args $arg"
done
env > /tmp/docker-env
sed -i s/idekey=.*/idekey=PHPSTORM/ /tmp/docker-env
docker run -e "PHP_IDE_CONFIG=serverName=phpunit-docker" \
   --net=host --env-file /tmp/docker-env --rm \
   -v /:/mnt -v /var/www:/var/www app php $args

Это решает несколько проблем


можно создать php.sh с этим кодом, и положить в любое место, например в /usr/local/bin,
и обращаться с ним вроде это настоящий php
phpstorm вызывая тесты создает /tmp/ide-phpunit.php который принимает env переменные
которые настраиваются в самой ide, поэтому я использую /tmp/docker-env
настройка --net=host решает все проблемы с сетью, например nslookup раньше выпадал
с ошибкой

Это не решает проблемы


явного указания idekey=PHPSTORM и PHP_IDE_CONFIG

Но всё равно PHPUnit тесты не запускаются, ругается composer


  PHP Fatal error:  Cannot redeclare    composerRequire7a368ac394ae1d2e857becf2a235ebaa()
(previously declared in    [APP_ROOT]/vendor/composer/autoload_real.php:56) in    [APP_ROOT]/vendor/composer/autoload_real.php
on line 59


Я подозреваю что это происходит потому что /tmp/ide-phpunit.php вызывает composer/autoload
для нахождения phpunit, и при запуске тесты тоже запускают этот же

    

Ответы

Ответ 1

В PhpStorm можно настроить запуск тестов через SSH. Ниже инструкция, как запустить
SSH-сервер в debian/ubuntu контейнере (docker image php:cli - это debian).

Зайдите в контейнер. Допустим, он называется phpapp

docker exec -it phpapp bash


Устанавливаем SSH-сервер

apt-get update; apt-get install openssh-server


Запускаем SSH-сервер. Почему-то нужно указывать полный путь.

/usr/sbin/sshd


Если будет ругаться, возможно, ему нужно создать какой-то каталог перед запуском

mkdir /var/run/sshd


Добавляем пользователя

adduser test


Выходим из контейнера - Ctrl+D

Пробрасываем 22-й порт контейнера на какой-то из локальных портов, например, 127.0.0.1:10022
(вместо 10022 можно выбрать любое число 1025-65535). Если запускаете на Windows через
VirtualBox/Vagrant/docker-machine, то пробрасывайте на 0.0.0.0:10022 и в VirtualBox
настройте проброску локального порта 10022 на порт 10022 в вашем VirtualBox.

Логинимся в контейнер - ssh test@127.0.0.1:10022, где test - это пользователь, которого
вы создали.

Устанавливать SSH в Docker считается плохим тоном, но пока в PhpStorm простая и красивая
интеграция с PHPUnit (не просто консоль, а список тестов и coverage) работает только
через SSH. На production так не делайте.


Ответ 2

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

Целесообразность создания composer-пакета для интерфейса

#php #composer

У меня есть 2 небольшие библиотеки (буквально по 1 классу) оформленные как пакеты
composer, они решают одинаковые задачи, просто разным подходом.

Без использования интерфейсов или абстракции, я их привел к единообразному API, и
у меня прям руки чешутся написать для них интерфейс (вот такой вот реверс). Но писать
одинаковые интерфейсы в разные репозитории - как-то совесть не позволяет.

Насколько это целесообразно под один интерфейс выделять целый пакет (возможно, composer.json
будет больше весить чем файл с интерфейсом)? Есть более красивые решения, без объединения
репозиториев?
    

Ответы

Ответ 1

Подойдите к вопросу практически.

Будет ли кто-нибудь использовать обе ваши либы одновременно?

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

Если ваш ответ да, то смысла в трех пакетах ради двух классов и одного интерфеса
вообще ноль. Если кому-то нужны две либы сразу, а они такие маленькие, то зачем вообще
делить то? Пусть будет одна со всеми функциями сразу.

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

Короче, не делайте простое сложно, код красивей не станет.

Задать Laravel и Composer определенную версию PHP

На сервере имеются разные версии PHP. От 5.2 до 7.0. По умолчанию используется (/usr/bin/php) 5.4. Менять, к сожалению нельзя. Но, в папках /opt/php/bin лежат другие версии интерпретатора.
Так вот, вопрос в том, как заставить Composer и Laravel использовать не /usr/bin/php, а /opt/php70/bin/php?
Larevel не проверял, но Composer, как я понял, проверяет целостность самого себя, так что "исполняемый" файл не изменить. Была идея заменить первую строчку (!#/usr/bin/env php) на что то свое, но не срослось. (а может быть я что то не то там прописывал)
Два дня уже копаю интернет, но так ни чего и не нашел.
На всякий случай, панель на сервере - ISPManager. Ось - CentOS 7

Ответ

В общем, спустя почти 2 года, снова встал этот вопрос.
В итоге, единственный выход, который я для себя нашел и который работает: заменить php "по умолчанию".
Переименовал /usr/bin/php в /usr/bin/php5
mv /usr/bin/php /usr/bin/php5
Создал симлинк на опциональный PHP версии 7.2 в /usr/bin/
ln -s /opt/php72/bin/php /usr/bin/php

Composer и stable версии

Веду небольшой пакет на github (оформлен в packagist), после создания релиза 2.0.0 - он показал его как стабильный. Потом, я нашел серьезную ошибку в реализации, и на сколько я понимаю систему версионности, т.к. API не менялось, после коммита создал релиз 2.0.1 (т.е. произошли исправления, не затрагивающие API), но packagist так и считает версию 2.0.0 стабильной. Как перевести его на новую версию?
UPDATE:
{ "name": "name/name", "description": "Desctiption", "authors": [ { "name": "AuthorName", "email": "email@gmail.com" } ], "license": "MIT", "require": { "php": ">=5.3.0" }, "require-dev": { "phpunit/phpunit": "4.7.*", "satooshi/php-coveralls": "dev-master" }, "autoload": { "psr-4" : { "NameSpace\\" : "src/" } } }

Ответ

В composer.json на github можете добавить version: "2.0.1" и еще новый тег v2.0.1. На packagist есть кнопка для обновления информации.
UPD
Так же вы можете создать новую ветку 2.0 в которой вести правки минорной версии и Packagist сразу их подцепит. Дока по тегам для композера
UPD 2
По наставлению @Etki – оказывается в composer.json действительно лучше не указывать версию. Документация
Соответственно добавление тега и/или ветки с версией будет достаточно.
UPD 3
Как выяснилось, проблема была на стороне https://poser.pugx.org, который кешировал информацию о пакете.

Cоздание и распространение пакета PHP+JS

Есть простая фреймворконезависимая библиотека на PHP для вывода статистики. К ней есть фронтенд, строящий диаграммы на JS+CSS, требующий еще и Сhart.js в зависимостях. Как распространять данную связку целиком? Сразу говорю, что бэкенд без фронтенда хоть и будет работать, но вряд ли кому-то пригодится. Весь цимес именно в связке.
Пока в голову пришли только такие варианты.
Все вместе - PHP+JS+СSS через Сomposer и какой-нибудь asset-менеджер. Разбить на два репозитория и распространять бэкенд - через Сomposer, а фронтенд через NPM/Bower. Использовать один репозиторий, но фронтенд ставить через NPM/Bower, а бэкенд через Сomposer.
Может есть еще способы? Как обычно распространяются подобные проекты?

Ответ

Давайте так рассуждать: фронтэнд от вашей библиотеки по-отдельности бесполезен.
Поэтому вижу только вариант распространения через Composer, с выкладкой кода на Github. Какую-то работоспособную версию Chart.js, конечно, прикладывайте к проекту, лицензия MIT это позволяет
Для удобства обновления Chart.js можно приложить и package.json, отметив этот факт в Readme.
Так можно получить из одного источника работоспособную библиотеку и сразу начинать ее использовать.

Почему при перезапуске phpStorm (Windows) слетает composer?

При перезапуске phpStorm и открытии проекта перестает работать composer. Приходится каждый раз заново открывать Tools/Composer/Init composer и указывать путь к php.exe и composer.path. Данная проблема наблюдается при открытии лишь некоторых проектов. Подскажите, в чем может быть проблема?
phpStorm 10.0.3

Ответ

Для того, чтоб работали настройки композера нужно выполнить следующие 2 простых условия.
Нужно чтоб был настроен интерпретатор PHP: Languages & Frameworks/PHP Interpreter (выбрать исполняемый файл PHP php.exe) чуть выше PHP language level должен соответствовать версии выбранного интерпретатора. Собственно, настроить сам композер. Для этого:
он должен быть доступен в проекте: либо установлен глобально, либо в папке проекта должен находиться файл composer.phar. Для глобальной настройки убедитесь, что команда composer в консоли выдает список команд. указать путь к используемому файлу composer.phar либо глобально доступному, либо локально установленном в проекте.
Возможные проблемы:
Файл композера недоступен для вашего проекта. Убедитесь, что в папке вашего проекта доступна команда composer для глобальной настройки или php composer.phar для локальной. В настройках PhpStorm указан НЕ тот файл composer.phar, который доступен в вашем проекте. PhpStorm хранит локальные настройки проекта в папке .idea. Убедитесь, что вы не перезаписываете, не удаляете и не изменяете эту папку для вашего проекта при перезагрузке. Убедитесь так же, что путь к проекту указан правильно и не был изменен при перезагрузке.
В конце хочется сказать, что вы очень ограничиваете ответы на ваш вопрос изначально сузив их до той части, которая уже не принесла вам положительного результата. Лучше бы вы спросили, как реализовать именно то, что вам нужно. Например, как установить новый пакет в проект при помощи композера? Возможно, и скорее всего, есть более простые пути решения вашей проблемы, о которых вы просто не знаете.

Целесообразность создания composer-пакета для интерфейса

У меня есть 2 небольшие библиотеки (буквально по 1 классу) оформленные как пакеты composer, они решают одинаковые задачи, просто разным подходом.
Без использования интерфейсов или абстракции, я их привел к единообразному API, и у меня прям руки чешутся написать для них интерфейс (вот такой вот реверс). Но писать одинаковые интерфейсы в разные репозитории - как-то совесть не позволяет.
Насколько это целесообразно под один интерфейс выделять целый пакет (возможно, composer.json будет больше весить чем файл с интерфейсом)? Есть более красивые решения, без объединения репозиториев?

Ответ

Подойдите к вопросу практически.
Будет ли кто-нибудь использовать обе ваши либы одновременно?
Если ваш ответ нет, то не заставляйте програмеров выкачивать сложные иерархии либ только чтобы сыкономить на одном файле. Мне нравятся либы без зависимостей, с ними мало проблем. Так как они сами по себе то никакие зависимости сломатся не могут, гемороя по минимуму. Тогда и в интерфейсе смысла не очень то много, это фиктивная абстракция которая никому не нужна.
Если ваш ответ да, то смысла в трех пакетах ради двух классов и одного интерфеса вообще ноль. Если кому-то нужны две либы сразу, а они такие маленькие, то зачем вообще делить то? Пусть будет одна со всеми функциями сразу.
Вот если бы ваши либы были дико сложными, с кучей кода, разными зависимостями, если бы использовались обе сразу, то тогда можно устраивать сложную иерархию пакетов, будет практический смысл.
Короче, не делайте простое сложно, код красивей не станет.