platformsh / legacy-cli

This is the legacy version of Platform.sh's command-line interface. The new version is at: https://github.com/platformsh/cli
https://docs.platform.sh/administration/cli.html
MIT License
221 stars 120 forks source link

Installing/Updating from own fork #359

Closed vincenzo closed 8 years ago

vincenzo commented 8 years ago

Hi all,

I am not quite sure this is the right place to talk about this, but I couldn't find anywhere else. As part of the project I work on, I have decided to implement some custom commands for the cli that will not be applicable to the general public. Therefore, the plan is to keep a private fork with all the additions in it and update the platform cli from there.

To test things, I've created a public fork for the time being: https://github.com/artetecha/platformsh-cli/

So, first thing was to edit my .composer/composer.json so that it looked as follows:

{
    "require": {
        "drush/drush": "6.4.0",
        "platformsh/cli": "dev-master"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/artetecha/platformsh-cli"
        }
    ]
}

This was done following composer's official documentation. Then, as suggested, I ran

$ composer global update platformsh/cli

First, the good news: it picked up my repo and it's pulling from there.

Now, the bad news.

The first time I ran the update, composer started scanning all the versions (supposedly looking at the tags on the repo). It made so many requests to Github that at some point asked me to generate a token as it had reached the maximum number of allowed requests.

I did that, just to get past that. And I eventually a problem with the resolution of the dependencies (I think). I can now get that any time I want, just by running the update again:

$ composer global update platformsh/cli
Changed current directory to /home/vagrant/.composer
Loading composer repositories with package information
Updating dependencies (including require-dev)          
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - platformsh/cli dev-master requires platformsh/client 0.1.25 -> satisfiable by platformsh/client[v0.1.25].
    - Conclusion: don't install platformsh/client v0.1.25
    - Can only install one of: platformsh/client[v0.3.0, v0.1.31].
    - Can only install one of: platformsh/client[v0.3.0, v0.1.31].
    - Can only install one of: platformsh/client[v0.3.0, v0.1.31].
    - platformsh/cli dev-master requires platformsh/client 0.3.0 -> satisfiable by platformsh/client[v0.3.0].
    - Installation request for platformsh/cli dev-master -> satisfiable by platformsh/cli[dev-master].
    - Installation request for platformsh/client == 0.1.31.0 -> satisfiable by platformsh/client[v0.1.31].

I must admit, I am kind of new to managing stuff with composer, so I am kind of stuck at this point.

Anyone willing to help me to move things forward?

pjcdawkins commented 8 years ago

Using composer global ... just means that your "project" is the folder ~/.composer. You probably want to manage your CLI modifications in a separate folder - run composer commands at the root of that folder without global.

I believe composer update <dep> attempts to update only that specific dependency, and so it is unable to update the dependency's dependencies to match. composer update works much better.

vincenzo commented 8 years ago

That makes sense @pjcdawkins, thanks.