Utilisez PHP composer pour cloner git repo

J'essaie d'utiliser composer pour cloner automatiquement un dépôt git à partir de github qui n'est pas dans packagist mais cela ne fonctionne pas et je ne peux pas comprendre ce que je fais de mal.

Je pense que je dois l'inclure parmi les "référentiels" comme ceci:

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

puis listez-le probablement dans la section "Requiert". Cela devrait être similaire à cet exemple mais cela ne fonctionne pas. Cela donne juste cette erreur:

Vos besoins n'ont pas pu être résolus en un ensemble de packages installables.

Quelqu'un a-t-il déjà essayé de faire quelque chose comme ça?

Au moment de la rédaction de cet article en 2013, c'était une façon de le faire. Composer a ajouté un support pour de meilleures façons: voir la réponse de @igorw

AVEZ-VOUS UN REPOSITORY?

Git, Mercurial et SVN sont pris en charge par Composer.

AVEZ-VOUS UN ACCÈS EN ÉCRIT AU REPOSITORY?

Oui?

LE REPOSITORY A-T-IL UN composer.jsonFICHIER

Si vous avez un référentiel dans lequel vous pouvez écrire: Ajoutez un composer.jsonfichier, ou corrigez l'existant, et N'utilisez PAS la solution ci-dessous.

Aller à @igorw de » réponse

N'UTILISEZ CECI QUE SI VOUS N'AVEZ PAS DE DÉPÔT
OU SI LE DÉPOSITAIRE N'A PAS composer.jsonD' UN ET VOUS NE POUVEZ PAS L'AJOUTER

Cela remplacera tout ce que Composer peut lire à partir du référentiel d'origine composer.json, y compris les dépendances du package et le chargement automatique.

L'utilisation du packagetype vous transférera le fardeau de tout définir correctement. Le moyen le plus simple est d'avoir un composer.jsonfichier dans le référentiel et de l'utiliser simplement.

Cette solution n'est vraiment que pour les rares cas où vous avez un téléchargement ZIP abandonné que vous ne pouvez pas modifier, ou un référentiel que vous ne pouvez que lire, mais il n'est plus maintenu.

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

Ce package est en fait disponible via packagist . Vous n'avez pas besoin d'une définition de référentiel personnalisée dans ce cas. Assurez-vous simplement d'ajouter un require(qui est toujours nécessaire) avec une contrainte de version correspondante.

En général, si un package est disponible sur packagist, n'ajoutez pas de dépôt VCS. Cela ralentira simplement les choses.

Pour les packages qui ne sont pas disponibles via packagist, utilisez un référentiel VCS (ou git), comme indiqué dans votre question. Lorsque vous le faites, assurez-vous que:

• Le champ "repositories" est spécifié dans le root composer.json (il s'agit d'un champ racine uniquement, les définitions de référentiel des packages requis sont ignorées)
• La définition des référentiels pointe vers un référentiel VCS valide
• Si le type est "git" au lieu de "vcs" (comme dans votre question), assurez-vous qu'il s'agit bien d'un dépôt git
• Vous avez un requirepour le package en question
• La contrainte dans le requirecorrespond aux versions fournies par le référentiel VCS. Vous pouvez utiliser composer show <packagename>pour trouver les versions disponibles. Dans ce cas, ce ~2.3serait une bonne option.
• Le nom dans le requirecorrespond au nom dans la télécommande composer.json. Dans ce cas, c'est le cas gedmo/doctrine-extensions.

Voici un exemple composer.jsonqui installe le même package via un référentiel VCS:

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

La documentation du référentiel VCS explique tout cela assez bien.

S'il existe un référentiel git (ou autre VCS) avec un référentiel composer.jsondisponible, n'utilisez pas de référentiel "package". Les dépôts de packages nécessitent que vous fournissiez toutes les métadonnées de la définition et ignoreront complètement tout composer.jsonprésent dans la dist et la source fournies. Ils ont également des limitations supplémentaires, telles que ne pas autoriser les mises à jour appropriées dans la plupart des cas.

Évitez les dépôts de packages ( voir aussi la documentation ).

Vous pouvez inclure le dépôt git dans composer.json comme ceci:

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

Dites simplement au compositeur d'utiliser la source si disponible:

composer update --prefer-source

Ou:

composer install --prefer-source

Ensuite, vous obtiendrez des packages sous forme de référentiels clonés au lieu de archives tar extraites, vous pourrez donc apporter des modifications et les valider. Bien sûr, en supposant que vous ayez des autorisations d'écriture / push sur le référentiel et que Composer connaisse le référentiel du projet.

Avertissement: Je pense que je peux répondre à une question un peu différente, mais c'est ce que je cherchais lorsque j'ai trouvé cette question, alors j'espère qu'elle sera également utile à d'autres.

Si Composer ne sait pas où se trouve le référentiel du projet ou si le projet n'a pas le fichier composer.json approprié, la situation est un peu plus compliquée, mais d'autres ont déjà répondu à de tels scénarios.

Je rencontrais l'erreur suivante: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.

Si vous forgez un autre dépôt pour apporter vos propres modifications, vous vous retrouverez avec un nouveau dépôt.

Par exemple:

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

La nouvelle URL devra aller dans votre section référentiels de votre composer.json.

N'oubliez pas que si vous voulez faire référence à votre fork comme my-foo/bardans votre section require, vous devrez renommer le package dans le composer.jsonfichier à l'intérieur de votre nouveau dépôt.

{
    "name":         "foo/bar",

=>

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

Si vous venez de bifurquer, le moyen le plus simple de le faire est de le modifier directement dans github.

Dans mon cas, j'utilise Symfony2.3.x et le paramètre de stabilité minimale est par défaut "stable" (ce qui est bien). Je voulais importer un dépôt pas dans packagist mais j'ai eu le même problème "Vos besoins n'ont pas pu être résolus en un ensemble de packages installables.". Il est apparu que le composer.json dans le dépôt que j'ai essayé d'importer utilise un "dev" à stabilité minimale.

Donc, pour résoudre ce problème, n'oubliez pas de vérifier le fichier minimum-stability. Je l'ai résolu en exigeant une dev-masterversion au lieu de mastercomme indiqué dans cet article .

Si vous souhaitez utiliser un composer.jsonGitHub, vous devriez regarder cet exemple (sous la section VCS).

La section package concerne les packages qui ne possèdent pas l'extension composer.json. Cependant, vous n'avez pas suivi cet exemple également ou cela aurait également fonctionné. Lisez ce qu'il dit sur les référentiels de paquets:

Fondamentalement, vous définissez les mêmes informations que celles incluses dans le référentiel du composeur packages.json, mais uniquement pour un seul package. Encore une fois, les champs minimum requis sont le nom, la version et soit de dist, soit de source.

J'essaie de rejoindre les solutions mentionnées ici car il y a quelques points importants à énumérer.

1. Comme mentionné dans la réponse de @ igorw, l'URL du référentiel doit être dans ce cas spécifiée dans le fichier composer.json, cependant puisque dans les deux cas le composer.json doit exister (contrairement à la 2ème façon @Mike Graf), le publier sur le Packagist est pas si différent (en outre, Github fournit actuellement des services de packages sous forme de packages npm), seule différence au lieu de saisir littéralement l'URL à l'interface de packagist une fois inscrit.

2. De plus, il présente un inconvénient: il ne peut pas s'appuyer sur une bibliothèque externe qui utilise cette approche car les définitions de référentiel récursives ne fonctionnent pas dans Composer. De plus, à cause de cela, il semble y avoir un "bogue" là-dessus, puisque la définition récursive a échoué au niveau de la dépendance, la resécification des dépôts explicitement à la racine ne semble pas être suffisante mais toutes les dépendances des packages devraient également être respécifié.

Avec un fichier de compositeur (réponse le 18 octobre 12 à 15:13 igorw)

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

Sans fichier de compositeur (réponse le 23 janvier 13 à 17:28 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"
}