为什么Composer安装不同的包？

I've been working with the Magento Firegento custom Composer installer, and I ran into this odd bit of Composer behavior I don't understand.

Consider the following dead simple composer.json file

{
    "require": {
        "magento-hackathon/magento-composer-installer": "*"
    }
}

If I run compser.phar install with this composer.json file, I get the following.

$ composer.phar install --no-dev 
Loading composer repositories with package information
Installing dependencies
  - Installing aoepeople/composer-installers (v0.0.1)
    Loading from cache

Writing lock file
Generating autoload files

From my mostly lay-person's understanding composer.phar, I've said

Hey, composer, please install the magento-hackathon/magento-composer-installer package from packagist.org

And composer has said back to me

Sir, yes sir! Here's the aoepeople/composer-installers package

I don't understand why composer installed aoepeople/composer-installers, when I asked for magento-hackathon/magento-composer-installer.

To be clear: I understand the reason magento-hackathon/magento-composer-installer wasn't installed is this is a package that lives in a different composer repository. My original mistake was not including this repository in my composer.json file.

However, it doesn't make sense to me that composer would install a different package than the one I asked for. When I search packagist there's no magento-hackathon/magento-composer-installer extension.

Why does packagist install a different extension? What's happening behind the scenes to make magento-hackathon/magento-composer-installer resolve to aoepeople/composer-installers? How/where in the composer source could I debug this sort of thing myself in the future?

Vinai published a great writeup on Magento and Composer here.

Quoting from there

Composer will use packagist.org to look where to get the libraries. Because Magento modules aren’t listed there, you will have to add the packages.firegento.org repository to the configuration as follows [...]

So you will need the repository

   "repositories":[
     {
       "type":"composer",
       "url":"http://packages.firegento.com"
     }
   ],

to get the magento composer installer.

And yes composer offers replacements. On the packaging entry for aoepeople/composer-installers you will notice the replaces section:

And since magento-hackathon/magento-composer-installer is not available on packagist composer will deliver you aoepeople/composer-installers.

The Packagist package at https://packagist.org/packages/aoepeople/composer-installers has metadata saying that it replaces the magento-hackathon/magento-composer-installer package. Packagist would then install this as it's the package that replaces what you asked for.

Docs here: https://getcomposer.org/doc/04-schema.md#replace

OK, so that's a weird behavior :) I'm the author of the aoepeople/composer-installers package and the idea behind this is that this package provides an alternative (very basic and simplified implementation of the composer package-type magento-module - and adds another type magento-source. I only want the installer to put the package in the right place - keeping it simple. That's why I decided to come up with an alternative package.

The reason why the aoepeople/composer-installer replaces the magento-hackathon/magento-composer-installer is because many Magento modules already come with a composer.json that requires the magento-hackathon/magento-composer-installer. In order to be able to seamlessly use the simpler installer that one is "pretending" to be the hackathon-installer. But unless you actively require aoepeople/composer-installers in your project's composer.json you should continue using the original installer as no Magento module's composer.json out there (not even ours) is directly referring to aoepeople/composer-installers.

The fact that packagist tries to be "smart" and returns a package that replaces a package that's not registered is new to me and - to be honest - very disturbing. While this might be intended behavior I share the opinion that this could easily be abused. I start liking Alan's idea to bypass packagist completely using "packagist":"disabled". Especially in the case of Magento modules this seems to happen easily because most of the Magento modules are unknown to packagist while being registered at packages.firegento.com only.

A simple quickfix/workaround to this specific situation could be to register magento-hackathon/magento-composer-installer on packagist.org.