Use PHP Composer para clonar git repo


111

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?

Respuestas:


110

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"
}

7
Reemplazar el repositorio de VCS con un repositorio de paquetes es una mala idea. El repositorio de destino ya tiene un composer.json, así que use un repositorio de vcs. Su ejemplo también rompe la carga automática e ignora el branch-alias.
igorw

1
@igorw, ¿puede vincular esa información para que yo y otros podamos entender la diferencia? Gracias.
Mike Graf

5
Como se explica en la página de repositorios, un repositorio de paquetes debe incluir toda la información. Si no agrega el autoloadcampo, no se incluirá. Básicamente, debe copiar y pegar toda la información de composer.jsonla definición del repositorio. El repositorio de VCS obtiene esa información directamente de VCS. Los beneficios de branch-aliasse explican en el documento de alias y en una publicación de blog que escribí .
igorw

2
¿Por qué todavía se vota a favor? Los documentos del redactor incluso afirman explícitamente que se deben evitar los repositorios de paquetes. Por favor, deje de fomentar las malas prácticas.
igorw

1
¿A qué me recomiendas que lo cambie entonces?
Mike Graf

146

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 ).


1
¡Ouu, gracias! No lo encontré porque pensé que se llamará después del repositorio git DoctrineExtensions.
martin

2
Mire siempre el nombre dado en composer.json.
igorw

16
-1 ¿Por qué está marcado como la respuesta correcta? Seguro que resolvió el problema del OP, pero Clarence y Mike Graf dieron respuestas al problema más general detrás de él. Es muy poco probable que alguien que busque una manera de incluir proyectos no empaquetadores quiera incluir DoctrineExtensions.
aefxx

2
@aefxx Mi respuesta lo hace , de hecho, también explican el problema general general, que es que el requirecampo debe ser especificado.
igorw

6
The VCS repo docs explain all of this quite well.... ¿qué?
hek2mgl

47

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"
}

1
Como se explicó en las otras respuestas anteriores: si tiene un repositorio, agregue un composer.jsonarchivo si es posible.
Sven

@Sven ... porque es imposible especificar un compromiso específico de otra manera?
Cees Timmerman

Gracias por compartir, me
ahorraste

Esto se ajusta para que sea general, pero por lo demás es básicamente una copia simple de la respuesta de Mike Graf, por lo que no estoy seguro de si general es mejor que ver una biblioteca en particular en la pregunta como ejemplo.
FantomX1

6

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.


3

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.


Tenga en cuenta que el nombre del paquete no refleja de ninguna manera la URL desde donde puede leer el repositorio. No existe un vínculo automático entre los dos, ambos se pueden elegir de forma independiente. La única información relevante sobre Composer es el nombre escrito en el nameatributo dentro composer.json.
Sven

2

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 .


4
Tuve el mismo problema, que se comenta aquí . Si tiene una referencia explícita (como un compromiso de git), parece que puede hacer algo como "dev-master#4536bbc166ada96ff2a3a5a4b6e636b093103f0e".
Blaskovicz

1

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.


0

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"
}
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.