@schlessera I don't think wp-cli/wp-cli#3921 fixed this issue. Composer still returns this error:

  Problem 1
    - Installation request for wp-cli/package-command dev-2a4ac19b859ac77c92e60efc972e539c6b834fb1 -> satisfiable by wp-cli/package-command[dev-2a4ac19b859ac77c92e60efc972e539c6b834fb1].
    - wp-cli/wp-cli dev-master requires wp-cli/package-command ^1.0 -> satisfiable by wp-cli/package-command[v1.0.0].
    - Can only install one of: wp-cli/package-command[v1.0.0, dev-2a4ac19b859ac77c92e60efc972e539c6b834fb1].
    - Installation request for wp-cli/wp-cli dev-master -> satisfiable by wp-cli/wp-cli[dev-master].

@danielbachhuber The issue is that Composer cannot rely on the fact that your dev branch automatically meets the ^1.0 requirement (it could include a breaking change, it could be something entirely different, ...).

That's why you need to explicitly tell it that your dev branch matches that requirement. You can do so by adding a branch alias to the wp-cli/package-command:

    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }

You have "minimum-stability": "dev" in the composer.json file. You need to add "prefer-stable": true as well, otherwise it will pull down the dev version of every single dependency, instead of the stable ones.

@schlessera Here's the fatal from removing the class_exists() check:

Also, we seem to be pulling in dev-master for composer/composer too. Is there a way to tie branch-alias to a specific project?

From our phone call today, the fatal from removing the class_exists() check is probably because the autoloader is bundled in the Phar, and then loaded a second time by package-command.php at a different path.

The prefer-stable should fix the issue of having the dev-master of composer/composer be pulled in.

But just for future reference, you can also define package-specific aliases from within the requiring package by adding them to the version string as follows:

require: {
   "vendor/package": "dev-whatever-branch as 1.2.5"
}

Some more specifics about the fatal:
Normally, the require_once directive would avoid loading the Composer autoloader a second time. However, in this case, as the paths are different (file:///some/folder/vendor/autoload.php vs phar:///vendor/autoload.php), the require_once doesn't recognize them being the same file.

Chatted in Slack, and decided to go with class_exists() for now https://wordpress.slack.com/archives/C02RP4T41/p1490886655640052

I think that the test failures after the latest changes are due to changed behaviour because of switching from included wp package to Composer-packaged wp package.

We will probably need to rethink these tests.

@schlessera I've just pushed some changes. The build should pass now.

The build still fails. It seems to be able to pull in wp-cli/google-sitemap-generator-cli.git:

Warning: Failed to execute git clone --mirror 'git@github.com:wp-cli/google-sitemap-generator-cli.git' '/tmp/wp-cli-home/.composer/cache/vcs/git-github.com-wp-cli-google-sitemap-generator-cli.git/'

Maybe GitHub rate limit?

Maybe GitHub rate limit?

Must be. It's flagged with the @github-api decorator. Test passes locally.

Updated to use ./bin/test.sh in 12f8777