composer/composer — pull request #379 by simensen (2012-03-03 05:50:29+00:00)
Title: Moving install related code from Composer\Command\InstallCommand to Composer\Install

This has been discussed on IRC several times. I have worked to try and build tests for the `install` method but the amount of dependencies makes testing extremely difficult. Especially for someone like me who has not done a lot of stuff with mocks in the past. (would love some help/direction on how to go about doing this)

I propose we move the code first and then I can start picking it apart and maybe refactor sections of this monolithic method into other methods or classes. I know I initially agreed to write tests first, move code second, so I'm not going to be surprised if this isn't going to get merged at this point. :) But as far as I can tell, this code is pretty well isolated at this point and it should either work or not.

I have a vested interest in getting this API closer to its final and stable state as I'm actively trying to integrate Composer into an application. There have been at least two other requests (that I know of) to be able to do something similar. I think the sooner it is decided how this code will be handled the better.

At the very least I hope to start some discussion on how this class should look behave.

Should some of the arguments be passed to the constructor? All of them? Which ones make sense? Is the naming choice acceptable? I know @Seldaek seemed to think this name sounded OK... not sure if there are any better choices or strong objections here. Should it be in its own namespace? ( Composer\Install\Install ? )