Use PHP Composer para clonar git repo

Estoy tratando de usar el compositor para clonar automáticamente un repositorio de git de github que no está en packagist, pero no funciona y no puedo entender qué estoy haciendo mal.

Creo que tengo que incluirlo entre "repositorios" así:

"repositories": [
    {
        "url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
        "type": "git"
    }
],

y luego probablemente incluirlo en la sección "requerir". Debería ser similar a este ejemplo, pero no funciona. Solo da este error:

Sus requisitos no se pudieron resolver en un conjunto de paquetes instalables.

¿Alguien ha intentado hacer algo como esto ya?

En el momento de escribir este artículo en 2013, esta era una forma de hacerlo. Composer ha agregado soporte para mejores formas: vea la respuesta de @igorw

¿TIENES UN DEPÓSITO?

Composer admite Git, Mercurial y SVN.

¿TIENE ACCESO POR ESCRITO AL REPOSITORIO?

¿Si?

¿EL REPOSITORIO TIENE composer.jsonARCHIVO

Si tiene un repositorio en el que puede escribir: Agregue un composer.jsonarchivo o arregle el existente, y NO use la solución a continuación.

Ir a la respuesta de @igorw

UTILICE ESTO SOLO SI NO TIENE UN REPOSITORIO
O SI EL REPOSITORIO NO TIENE composer.jsonY NO PUEDE AGREGARLO

Esto anulará todo lo que Composer pueda leer del repositorio original composer.json, incluidas las dependencias del paquete y la carga automática.

El uso del packagetipo transferirá la carga de definir correctamente todo sobre ti. La forma más fácil es tener un composer.jsonarchivo en el repositorio y simplemente usarlo.

Esta solución solo es para los casos excepcionales en los que tiene una descarga ZIP abandonada que no puede modificar, o un repositorio que solo puede leer, pero ya no se mantiene.

"repositories": [
    {
        "type":"package",
        "package": {
          "name": "l3pp4rd/doctrine-extensions",
          "version":"master",
          "source": {
              "url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
              "type": "git",
              "reference":"master"
            }
        }
    }
],
"require": {
    "l3pp4rd/doctrine-extensions": "master"
}

Ese paquete, de hecho, está disponible a través de packagist . En este caso, no necesita una definición de repositorio personalizada. Solo asegúrese de agregar un require(que siempre es necesario) con una restricción de versión coincidente.

En general, si un paquete está disponible en packagist, no agregue un repositorio de VCS. Simplemente ralentizará las cosas.

Para los paquetes que no están disponibles a través de packagist, use un repositorio VCS (o git), como se muestra en su pregunta. Cuando lo haga, asegúrese de que:

• El campo "repositorios" se especifica en la raíz composer.json (es un campo solo de raíz, las definiciones de repositorio de los paquetes requeridos se ignoran)
• La definición de repositorios apunta a un repositorio VCS válido
• Si el tipo es "git" en lugar de "vcs" (como en su pregunta), asegúrese de que sea un repositorio git
• Tienes un requirepaquete para el paquete en cuestión.
• La restricción en requirecoincide con las versiones proporcionadas por el repositorio de VCS. Puede utilizar composer show <packagename>para buscar las versiones disponibles. En este caso ~2.3sería una buena opción.
• El nombre en el requirecoincide con el nombre en el control remoto composer.json. En este caso, lo es gedmo/doctrine-extensions.

Aquí hay una muestra composer.jsonque instala el mismo paquete a través de un repositorio de VCS:

{
    "repositories": [
        {
            "url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
            "type": "git"
        }
    ],
    "require": {
        "gedmo/doctrine-extensions": "~2.3"
    }
}

Los documentos de repositorio de VCS explican todo esto bastante bien.

Si hay un repositorio de git (u otro VCS) con un repositorio composer.jsondisponible, no use un repositorio de "paquetes". Los repositorios de paquetes requieren que proporciones todos los metadatos en la definición e ignorarán por completo cualquier composer.jsonpresente en la fuente y dist proporcionados. También tienen limitaciones adicionales, como no permitir actualizaciones adecuadas en la mayoría de los casos.

Evite repositorios de paquetes ( consulte también los documentos ).

Puede incluir el repositorio de git en composer.json de esta manera:

"repositories": [
{
    "type": "package",
    "package": {
        "name": "example-package-name", //give package name to anything, must be unique
        "version": "1.0",
        "source": {
            "url": "https://github.com/example-package-name.git", //git url
            "type": "git",
            "reference": "master" //git branch-name
        }
    }
}],
"require" : {
  "example-package-name": "1.0"
}

Solo dile al compositor que use la fuente si está disponible:

composer update --prefer-source

O:

composer install --prefer-source

Luego, obtendrá los paquetes como repositorios clonados en lugar de archivos tar extraídos, por lo que puede realizar algunos cambios y confirmarlos. Por supuesto, suponiendo que tenga permisos de escritura / inserción en el repositorio y que Composer conozca el repositorio del proyecto.

Descargo de responsabilidad: creo que puedo responder una pregunta un poco diferente, pero esto era lo que estaba buscando cuando encontré esta pregunta, así que espero que también sea útil para otros.

Si Composer no sabe dónde está el repositorio del proyecto, o si el proyecto no tiene el composer.json adecuado, la situación es un poco más complicada, pero otros ya respondieron esos escenarios.

Me estaba encontrando con el siguiente error: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.

Si está bifurcando otro repositorio para realizar sus propios cambios, terminará con un nuevo repositorio.

P.ej:

https://github.com/foo/bar.git
=>
https://github.com/my-foo/bar.git

La nueva URL deberá ir a la sección de repositorios de su composer.json.

Recuerde que si desea hacer referencia a su bifurcación como my-foo/baren la sección de requisitos, tendrá que cambiar el nombre del paquete en el composer.jsonarchivo dentro de su nuevo repositorio.

{
    "name":         "foo/bar",

=>

{
    "name":         "my-foo/bar",

Si acaba de bifurcar, la forma más fácil de hacerlo es editarlo directamente dentro de github.

En mi caso, uso Symfony2.3.xy el parámetro de estabilidad mínima es por defecto "estable" (lo cual es bueno). Quería importar un repositorio no en packagist pero tenía el mismo problema "Sus requisitos no se pudieron resolver en un conjunto de paquetes instalable". Parecía que el composer.json en el repositorio que intenté importar usaba un "dev" de estabilidad mínima.

Entonces, para resolver este problema, no olvide verificar el minimum-stability. Lo resolví requiriendo una dev-masterversión en lugar de la masterque se indica en esta publicación .

Si desea utilizar un composer.jsonarchivo de GitHub, consulte este ejemplo (en la sección VCS).

La sección del paquete es para paquetes que no tienen la extensión composer.json. Sin embargo, no siguió ese ejemplo tan bien o también habría funcionado. Lea lo que dice sobre los repositorios de paquetes:

Básicamente, define la misma información que se incluye en el repositorio del compositor packages.json, pero solo para un único paquete. Nuevamente, los campos mínimos requeridos son nombre, versión y dist o source.

Intento unir las soluciones mencionadas aquí, ya que hay algunos puntos importantes que deben enumerarse.

1. Como se menciona en la respuesta de @ igorw, la URL del repositorio debe estar especificada en ese caso en el archivo composer.json, sin embargo, dado que en ambos casos el composer.json debe existir (a diferencia de la segunda forma de @Mike Graf), publicarlo en el Packagist es no es muy diferente (además, Github actualmente proporciona servicios de paquetes como paquetes npm), la única diferencia en lugar de ingresar literalmente la URL en la interfaz de packagist una vez que se registra.

2. Además, tiene el inconveniente de que no puede depender de una biblioteca externa que utilice este enfoque, ya que las definiciones de repositorio recursivas no funcionan en Composer. Además, debido a esto, parece haber un "error", ya que la definición recursiva falló en la dependencia, volver a especificar los repositorios explícitamente en la raíz no parece ser suficiente, pero también todas las dependencias de los paquetes deberían ser respecificado.

Con un archivo de compositor (contestado el 18 de octubre de 2012 a las 15:13 igorw)

{
    "repositories": [
        {
            "url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
            "type": "git"
        }
    ],
    "require": {
        "gedmo/doctrine-extensions": "~2.3"
    }
}

Sin archivo de compositor (contestado el 23 de enero de 2013 a las 17:28 por Mike Graf)

"repositories": [
    {
        "type":"package",
        "package": {
          "name": "l3pp4rd/doctrine-extensions",
          "version":"master",
          "source": {
              "url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
              "type": "git",
              "reference":"master"
            }
        }
    }
],
"require": {
    "l3pp4rd/doctrine-extensions": "master"
}