Add phpunit as a development dependency

[cabello]

So executing composer.phar install --dev will install phpunit.

To execute the test suite just run:

$ vendor/bin/phpunit test/

[nickl-]

@cabello Thank you for the PR.

Has this become the preferred way to install phpunit as Foundation currently relies on pear as per

$ make install-phpunit

Not sure that you will need both....

[cabello]

I don't know which way of installing phpunit is the most popular nowadays, what I like about composer is that it doesn't require sudoer and it's sandboxes everything inside the project folder, look at the install-phpunit command:

install-phpunit: .check-foundation
    @echo "Attempting to download and install PHPUnit. This will likely require sudo."
    @pear channel-info pear.phpunit.de > /dev/null || pear channel-discover pear.phpunit.de || pear channel-update pear.phpunit.de
    @pear channel-info pear.symfony.com > /dev/null || pear channel-discover pear.symfony.com || pear channel-update pear.symfony.com
    @pear install --alldeps --soft pear.phpunit.de/PHPUnit

With composer you can have a project using phpunit 3.0.* and another one using 3.4.* without then affecting each other nor the system they are running on.

[nickl-]

@cabello if I am not mistaken Foundation will install pear in your home folder instead of /usr/lib/php which does not require sudo and if what you are suggesting is to add phpunit by default then wouldn't you be better served by a global library in any case?

I see the make target still warns about sudo this may very well be wrong.

 @echo "Attempting to download and install PHPUnit. This will likely require sudo."

Please verify and if you want to roll a PR to fix that I will gladly merge. Please don't let my disagreements demotivate you from contributing and that said, you are always welcome still to convince me otherwise =)

Send me a 👍 if you're cool!

[cabello]

Hi @nickl- I tried to install phpunit using make install-phpunit and it failed without sudo, after using sudo my phpunit was installed on:

$ which phpunit
/usr/local/bin/phpunit

I am using Mac Mavericks and homebrew.

[nickl-]

This is odd....

My /usr/local/bin belongs to nickl:staff and does not require sudo with homebrew on 10.8.5 has this policy changed? Can you locate the the pear installation folder ( default is usually ${prefix}/lib/php/PEAR prefix in your case is probably /usr/local )

Do you agree with my assessments so for?

I agree that using sudo for pear is a pain and we can certainly look at a remedy for that.

[cabello]

My /usr/local/bin belongs to root, but the things inside it belongs to my user. My PEAR installation is on /usr/local/lib/php/PEAR.

I understand your argument and it works well, however nowadays people (like myself) prefer to install the dependencies separated from the system or a specific user account to avoid dependencies conflicts. I've worked in many projects that a minor version would crash our application so we would rollback to the previous one and if by the time it was not fixed yet we installed another project with the most updated version (because the bug was not affecting this project code) we would have a conflict, needing to install the dependencies in different places and have to manage it manually.

This concept of sandboxing the project dependencies is not new, but it was migrated from being optional (install with PREFIX=/foo/bar) to builtin ("automatic"), examples are:

• node and npm
• python and virtualenv
• ruby and gem
• php and composer

I've being using composer for a while, and it's getting more mature and stable each day.

My workflow for working in new projects nowadays is:

$ git clone ssh://...project.git
$ cd project
$ composer.phar install --prefer-source --dev
$ vendor/bin/phpunit 

What's is nice about it, is that I don't need to worry that this project is really outdated and is using Symfony 2.0, because it will work and run nicely. 😄

[alganet]

Unfortunately, Composer wasn't so popular (and far from stable) at the time. I do agree that its workflow has become preferrable and Foundation may need an update, but I'm not sure the composer.json dependenct is the best option. The file is there just to be indexed by Packagist. Foundation manages its own dependencies and it would be nice to add PHPUnit (in a project-centric way using Composer) installation as a target, although I'm not sure which target. Perhaps the initial setup. PEAR is still needed to make multiple packages though.

I'm not that fond of this design as I used to be, but I believe it is important to keep its conceptual integrity. People are used to just run "wget git.io/Makefile && make foundation" then having a PHPunit installed, we need to do that for people who prefer composer as well. Perhaps identify which package manager is more suited for the job, which brings me back to aero, a project which branched from Foundation just to manage multi-package-manager environments. We were discussing about Composer behavior there a while ago.