el package de repository personalizado del compositor no puede extraer la dependencia

Enfrentando un problema con el compositor. Tengo un proyecto principal en el que estoy trabajando con algunas bibliotecas pequeñas que construí y que quiero compartir más fácilmente entre mis proyectos. No están listos para su lanzamiento, por lo que no quiero agregarlos a packagist, pero cuando requiero 1 que requiera otro, generará un error a less que advierta ese repository personalizado también en mi master composer.json

Además, el requisito terciario no puede resolver las bibliotecas packagist

Your requirements could not be resolved to an installable set of packages. Problem 1 - ethereal/simpleCache dev-master requires pnetworkingis/pnetworkingis ^1.1@dev -> no matching package found. - ethereal/simpleCache dev-master requires pnetworkingis/pnetworkingis ^1.1@dev -> no matching package found. - Installation request for ethereal/simplecache dev-master -> satisfiable by ethereal/simpleCache[dev-master]. 

Proyecto Principal composer.json:

 { "name": "ethereal/SimpleTable", "type": "project", "repositories": [ { "type": "vcs", "url": "https://github.com/mathus13/SimpleConfig.git" } ], "require": { "php": ">=5.3.9", "doctrine/dbal": "^2.6@dev", "ethereal/SimpleConfig": "dev-master" }, "require-dev": { "phpunit/phpunit": "~4.8" }, "autoload": { "psr-4": { "Ethereal\\": "lib" } } } 

Biblioteca de configuration: al ejecutar la actualización del compositor en SimpleTable, Caché simple no se includeá a less que se requiera explícitamente en SimpleTable.

 { "name": "ethereal/SimpleConfig", "type": "project", "version": "0.0.1", "repositories": [ { "type": "vcs", "url": "https://github.com/mathus13/SimpleCache.git" } ], "require": { "php": ">=5.3.9", "ethereal/SimpleCache": "dev-master" }, "require-dev": { "phpunit/phpunit": "~4.8" }, "autoload": { "psr-4": { "Ethereal\\": "lib" } } } 

biblioteca de caching: al ejecutar la actualización del compositor en SimpleTable, pnetworkingis no se puede resolver.

 { "name": "ethereal/simpleCache", "type": "project", "version": "0.0.1", "require": { "pnetworkingis/pnetworkingis": "^1.1@dev", "php": ">=5.3.9" }, "require-dev": { "phpunit/phpunit": "~4.8" }, "autoload": { "psr-4": { "Ethereal\\": "lib" } } } 

ethereal/SimpleTable depende de ethereal/SimpleConfig en la estabilidad de desarrollo, que depende de ethereal/SimpleCache en la estabilidad de desarrollo, que depende de pnetworkingis/pnetworkingis en la estabilidad de desarrollo (la versión 1.1 aún no se ha lanzado).

Los packages incluidos en el package principal no pueden definir ninguna estabilidad, la única estabilidad permitida es la del package principal. Y eso es "estable" por defecto.

Hizo UNA exception de esta regla dependiendo de "dev-master" para SimpleConfig ", pero esto no es henetworkingado.

Tienes múltiples soluciones:

  1. Etiqueta tu software. Las tags lo declaran más estable que "dev", y generalmente es una buena idea usar solo software labeldo en producción.
  2. Incluya TODOS sus packages que sean necesarios en el package principal, incluso si no se usan directamente. Esto agregará excepciones de la estabilidad general para ellos y permitirá a Composer resolver cualquier dependencia secundaria.
  3. Puede agregar "minimum-stability":"dev" al composer.json principal, pero esto también permitirá que todos los demás packages se instalen desde una twig. Sin embargo, usar twigs es algo muy malo, porque no se puede volver fácilmente a la versión que estaba funcionando antes de realizar la actualización: el puntero de la twig se mueve solo hacia adelante. Solo las tags apuntarán al mismo software para siempre.
  4. Agregar "prefer-stable":true" es un tipo de solución para el problema que 3 presenta para los packages que ya están disponibles en una versión de lanzamiento estable. Sin embargo, todavía tiene el problema de no poder volver a sus propios packages" versiones anteriores, porque está usando una twig.

Si todavía está desarrollando estos packages, dependiendo de las sucursales puede parecer necesario. Sin embargo, un buen package podrá desarrollarse y probarse de manera autónoma, con apenas un código extraño aparte de las definiciones de interfaz (que se usarán para simular todo), por lo que todos los códigos se combinan en repositorys con las twigs revisadas normalmente. es una invitación para escribir código que no está claramente separado.

Si alguno de estos packages ya está hecho (yo diría "lo suficientemente bueno"), márquelo y dependa de esa versión en lugar de una twig. Siempre puede lanzar nuevas versiones si encuentra errores o desea agregar nuevas características.