Compositeur - à l'aide d'un référentiel local

Je suis un Compositeur débutant et je suis en train de faire un projet dépendant de l'autre, tandis que les deux projets n'existent que sur ma machine locale.

Le compositeur.json dans mon projet de bibliothèque (ProjectA) est:

{
    "name" : "project/util",
    "type" : "library"
}

J'ai initialisé git dans le dossier de base de ce projet.

Mon compositeur.json dans le projet en fonction sur le premier (Projetb):

{
    "repositories": [
        {
            "name" : "util", 
            "type" : "git",
            "url" : "/d/workspaces/util"
        }   
    ],

    "require": {
        "project/util" : "*"
    },
}

Quand je lance composer install de Projetb, j'obtiens l'erreur suivante:

[RuntimeException]
Failed to clone , could not read packages from it
fatal: repository '' does not exist

J'asume quelque chose de mal avec l'url du référentiel, mais je ne suis pas sûr de ce que d'autre à y écrire.

InformationsquelleAutor Banana | 2013-07-02
  1. 41

    Autoload local package à l'aide de compositeur (sans aller jusqu'à packagist chaque fois que vous changer).

    Il existe de nombreuses façons de le faire, je vais être couvrant 2 d'entre eux:

    Dans tous les cas, nous disposons de 2 parties principales:

    - le forfait local (le code que nous ne voulons pas publier sur packagist pour être en mesure d'autoload dans notre projet, compositeur).

    - le projet principal (le code de base que doit utiliser le code du package, peut être un autre paquet et ou de projets).

    Méthode 1: (en direct de l'espace de noms)

    Ouvrir le projet principal composer.json fichier et chargement automatique du forfait local des espaces de noms en utilisant une méthode quelconque (PSR-4, PSR-0, ...).

    exemple:

    si dans le compositeur.json d'un forfait local, nous avons:

      "autoload": {
    "psr-4": {
      “Local\\Pack\\": "library"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Local\\Pack\\Tests\\": "tests"
    }
  },

    puis dans le compositeur.json de l'objectif principal du projet nous devrions avoir:

      "autoload": {
    "psr-4": {
      "Mahmoudz\\Project\\": "src",
      "Local\\Pack\\": "../path/to/local/pack/library”                   << referencing the other local package
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Mahmoudz\\Project\\Tests\\": "tests"
    }
  },

    Avantages:

    - vous n'avez pas touche le répertoire vendor (course compositeur de mise à jour par erreur ne sera pas annuler vos modifications locales)

    - vous n'avez pas besoin de votre colis sur packagist utiliser

    - vous travaillez dans un endroit (le forfait local) et les modifications sont automatiquement chargées dans le projet principal

    Inconvénients:

    - vous ne pouvez pas publier le compositeur.json sur la production (besoins d'édition avant de les publier pour exiger le réel paquet)

    Méthode 2: (référentiel local)

    Télécharger le package local à partir d'un référentiel local.

    paquet:

    1. initialiser git dans l'ensemble (même si vous ne voulez pas l'utiliser - pas besoin de commettre quoi que ce soit)

    2. ajouter compositeur.fichier json. Dans le fichier, assurez-vous d'avoir les éléments suivants: 

    "name": "vendor-name/package-name",  

"autoload": { …   //use whichever method you prefer, but make sure it’s being loaded correctly

"minimum-stability": "dev"
    1. composer dump-autoload

    projet principal:

    1. modifier votre compositeur.json pour contenir les éléments suivants:

      "repositories": [
    {
      "type": "vcs",
      "url": "/full/path/to/the/local/package/package-name"
    }
  ],
  "require": {
    "vendor-name/package-name": "dev-master"
  },
    1. compositeur fournisseur de mise à jour-name/nom-du-paquet
    2. maintenant vérifier que votre fournisseur de répertoire, vous devriez voir le vendeur-nom/nom - du-paquet

    REMARQUE: chaque fois que vous faites le changement dans le forfait local (pas le vendeur) vous avez besoin de git commit ensuite, vous pouvez composer mise à jour de l'objectif principal du projet est d'avoir la dernière copie de l'opération pour le projet principal fournisseur de répertoire.

    Avantage:

    - vous ne touchez pas le vendeur de répertoire (course compositeur de mise à jour par erreur ne sera pas annuler vos modifications locales) - vous n'avez pas besoin de votre colis sur packagist utiliser

    Inconvénient:

    - vous avez à garder de commettre vos modifications (dans le package local), puis en exécutant compositeur de mise à jour dans le projet principal

    - vous ne pouvez pas publier le compositeur.json sur la production (besoins d'édition avant de les publier pour exiger le réel paquet)

    • Merci, excellent! remarque: si vous utilisez-vous le cv approche (#2), n'oubliez pas de valider votre compositeur.json changements. Facile à oublier et vous serez gratter la tête pour lesquelles le compositeur est barfing votre colis avec le "package version introuvable erreurs".
    • Votre première methode a sauvé ma vie! Bravo!
    • deuxième méthode et @mangonights commentaire m'a sauvé aussi...merci à vous tous bro
    • Un autre avantage de la seconde approche au cours de la première est l'accessibilité du code de l'IDE pour la complétion de code.
    • J'ai utilisé la deuxième méthode et j'ai eu cette erreur: Pas de permis de compositeur.json a été trouvé dans n'importe quelle branche ou une étiquette de ..., n'a pas pu charger un package à partir d'elle. Et pour y remédier j'ai utilisé @mangonights répondre, et engage des modifications à mon dépôt local et qui a résolu mon problème
    • La méthode 1 est vraiment génial en termes de dev de la productivité, puisque je n'ai pas à perdre de temps pour "compositeur de mise à jour de la commande". Cependant, compositeur Autochargeur ne pas faire face bien avec dépendances transitives. En d'autres termes, si "ProjectA" dépend de "Projetb" et ci repose sur des "ProjectC", puis la Méthode 1 n'est pas vraiment de travail, à moins que je spécifier explicitement dans ProjectA du compositeur.fichier json qui "ProjectA" dépend à la fois de "Projetb/ProjectC". Mais cette approche ne tient pas compte de l'échelle dans le cas où vous 20+ petits projets. L'autochargeur de gestion devient cauchemar. @Mahmoud, avez-vous des idées à ce sujet?

    InformationsquelleAutor Mahmoud Zalt
  2. 23

    Je pense que vous avez juste la syntaxe de mal. Le type doit juste être VCS, puis compositeur chiffres ce type de VCS il est.

    Dans votre projet B, l'entrée pour les dépôts doivent être:

    "repositories": [
    {
        "type": "vcs",
        "url" : "/d/workspaces/util"
    }
],

    Vous n'avez pas besoin de nom de quelle bibliothèque est disponible dans /d/workspaces/util. Compositeur va scanner le compositeur.fichier json dans ce répertoire et de savoir ce que le nom du projet est disponible ici, et d'utiliser le projet à partir de ce répertoire, de préférence à une version répertoriés sur packagist ou d'un autre dépositaire.

    • Bon, quand je change de vcs, j'obtiens ce message: [Exception Runtime] Répertoire n'existe pas: /d/espaces de travail/util
    • Er, vraisemblablement le répertoire n'existe pas, ou n'est pas accessible?
    • Je pense que le répertoire est juste mal orthographié. Êtes-vous sûr que vous avez à offrir comme /d/workspaces/util et non pas comme d:/workspaces/util?
    • Comment a-t-elle être fournie?
    InformationsquelleAutor Danack
  3. 2

    En plus de Danack la solution: Changer le chemin d'accès à partir de /d/d:/fonctionné pour moi.

    Comme ceci:

    "repositories": [
    {
        "type": "vcs",
        "url" : "d:/workspaces/util"
    }
],
    InformationsquelleAutor Max