I've looked through this code - I have several such needs for packaging PHP dependencies - and have decided against using it for several reasons:
- Like most code coming from the Symfony community, it is built Java-style. Not a bad thing, but many things, such as dependency checking or version management, can be done in much simpler ways with less code
- PHP 5.3 only. Thanks, but no thanks. I know everyone is in a rush to promote 5.3, but I feel as though it can be done in such a way as to gracefully degrade and support older versions of PHP quite easily.
- Has dependencies on Symfony projects. That is a great way to have other frameworks adopt your tools! I'm sure this is going away, especially if they want framework-wide support.
That said, I'm jealous. I've been working on something similar for a few months in private and this is already on Github. If they can iron out my above issues, I'll be happy.
- Java-style. You don't like it, I'd argue it's not Java-style, but I know what you mean. I don't think this is worth debating much, it's just opinions :)
- PHP 5.3. Yes. 5.2 has been EOL for almost 1 year now (http://www.php.net/archive/2010.php#id2010-12-16-1), 5.4 is coming fast. I don't mean to be harsh but you will have to get over this one. ZF2, Symfony2, Flow3 are built on 5.3. Drupal8 will be too. Typo3 v5 will be.
- Dependencies on Symfony Components. We are trying to build a package manager here. Something that shold help and promote code re-use, and you would like us to avoid re-using code in the process? I think this is missing the point. Also, you have to realize that most end users will never have to see that, since they will only interact with the "binary" composer.phar file.
- Yeah, I just don't like it. But it's a minor niggle.
- Sorry, coming from the CakePHP world, we just migrated to PHP5.2. And yes, using < PHP5.2 is common enough - fucking CentOS - that we should still support it. I also work with Lithium, which embraces 5.3 as much as it can, but I don't see the need for doing so in all cases. So yeah, you can be harsh, but I'll be realistic.
- If all I'm working with is the phar, sure. But if we downport to 5.2, nay. Also, PHP frameworks tend to not depend upon each other's libraries too often. I don't see your CLI implementation being pulled into an official Zend package manager for example.
I'm definitely following along on Github, and have been for quite a while.
Why would it matter how Composer itself is built? It is just a tool you use to manage your dependencies and install your project. And all of it comes as a single phar.
- Like most code coming from the Symfony community, it is built Java-style. Not a bad thing, but many things, such as dependency checking or version management, can be done in much simpler ways with less code
- PHP 5.3 only. Thanks, but no thanks. I know everyone is in a rush to promote 5.3, but I feel as though it can be done in such a way as to gracefully degrade and support older versions of PHP quite easily.
- Has dependencies on Symfony projects. That is a great way to have other frameworks adopt your tools! I'm sure this is going away, especially if they want framework-wide support.
That said, I'm jealous. I've been working on something similar for a few months in private and this is already on Github. If they can iron out my above issues, I'll be happy.