Composer-like installation procedure, composer.json

olegstepura commented 12 years ago

Hi!

It would be nice to have an ability to install phpunit the way composer is installed.

So running tests like php phpunit.phar ./ and downloading phpunit like curl -s http://phpunit.de/installation | php or just wget http://phpunit.de/pnpunit.phar is very easy and does not require to have pear installed

There already is an attempt to create a phar from PHPUnit https://github.com/igorw/phpunit-phar

Also having composer.json inside phpunit for all it's dependencies is also a good thing. And a package registered at packagist.org as well.

Links:

sebastianbergmann commented 12 years ago

Creation of the PHAR should be taken care of by PHPUnit (and is being worked on in master).

olegstepura commented 12 years ago

Ok, will you add composer.json?

sebastianbergmann commented 12 years ago

I do not use Composer, so I cannot add a composer.json since I would not be able to test it. Why do I not use Composer? Because I fail to see the need for a replacement of the PEAR Installer. Except when you are on non-UNIX platforms such as MacOS X or Windows, the PEAR Installer "just works". Unless I see a compelling argument for using Composer over the PEAR Installer I will continue to only support the PEAR Installer.

Of course, once the remaining issues with the phpunit.phar are sorted, the PHAR will be officially supported as well.

olegstepura commented 12 years ago

Ok, it's your point of view and I respect it. Thanks!

edorian commented 12 years ago

Related #479

edorian commented 12 years ago

Oh just to leave a trail here an additional note:

Igors phar (that he build after I complained on stackoverflow about not having a phpunit.phar iirc) does not properly handle cli parameters (hence we don't use it).

Both phars currently don't work with process isolation but if you don't need that feature the one that phpunit can build works out (as far as I'm aware. Nothing official).

Just to leave a status here :)

ghost commented 12 years ago

@sebastianbergmann take a look at http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php when you have time. It has some compelling reasons.

grEvenX commented 12 years ago

+1 on composer

c33s commented 12 years ago

+1 on composer (i use windows, if this helps...)

domnikl commented 12 years ago

+1 on composer

catacgc commented 12 years ago

+1 for composer. The need for a PEAR replacement should become obvious when you read the article @drak mentioned. Moreover your argument about OS'es doesn't stand: Windows is used by many PHP developers (even though is not the ideal development platform for PHP) and OSX is a UNIX based OS.

The most important issue that composer fixes is the system wide installation that PEAR does by default. On a production env this may not be a big issue, but on a development machine where you usually host many projects this is the reason why we stopped using PEAR

jpic commented 12 years ago

Compare PEAR to its equivalent in any other language (python, perl, ruby ...). And you'll see that it's pretty limited despite the bloat that got in there. I think it's always good to learn about another language's package manager and see how package management can be objectively awesome.

cballou commented 12 years ago

composer++

PEAR is dated and the community support behind Composer/Packagist is growing rapidly. I think the subject needs more discussion before a preemptive close.

sebastianbergmann commented 12 years ago

The article you and @drak refer to does not convince me that Composer is THE replacement for PEAR. You are mixing the different meanings of PEAR. PEAR, as in pear.php.net, should die, IMHO. There is no need for a central package repository. PEAR, as in the PEAR Installer, works just fine -- at least for me.

edorian commented 12 years ago

After talking to the composer devs we agreed that it would be nice to have phpunit installable via composer even so it doesn't make all that much sense for dev tools.

I definitely see the "ease of use" part but you don't really want phpunit to be part of your projects composer.json anyways (why should people using your lib install phpunit?).

The solution preferred by everyone I talked to seems to be "Just give me a phar" and we are working on that.

In the meantime I think it is worthwhile to check out if #pirum 1.1 with the announced 'composer support by reading the pear.xml feature would solve the issue of having to deal with pear for people that don't want to :)

I didn't try it yet but if it works it would be a nice solution that wouldn't require someone creating composer.json files for all parts of phpunit and making that work. (I assume that is why nobody sent a pull request yet? :) )

To sum up:

Composer support will happen if someone does it
Maybe Pirum 1.1 will 'just make it work', I will look into the details tonight. - As far as i can tell there are no docs for it on the pirum site yet
For dev tools: phar >> package manager stuff

If phpunit wouldn't have the process-isolation feature the phar would already work but making that feature work requires a good amount of addition effort, hence the "pending" status.

catacgc commented 12 years ago

Yes maybe Composer is not THE replacement for PEAR. But it fixes the limitations PEAR has, it has a small footprint, it is very easy to deploy on any platform, it makes it easy to maintain your private repositories, it promotes today's coding standards (see the psr-0 section http://nelm.io/blog/2011/12/composer-part-2-impact/), it has a great community behind it and an extensible code base. It is not by any means THE complete solution but it is in many respects THE BETTER one. Anyway, ultimately you decide where PHPUnit will go in the future, and you did a great job so far :) . Cheers

ghost commented 12 years ago

@sebastianbergmann Composer does not rely on a central repo, it's completely decentralised.

ghost commented 12 years ago

@edorian I think another reason why there haven't been any pull requests is the fear it will not get merged, but if you say it will get merged, then I am very sure a PR will come.

sebastianbergmann commented 12 years ago

pear.phpunit.de already uses Pirum 1.1 and http://pear.phpunit.de/packages.json exists. Does it help?

edorian commented 12 years ago

@drak iirc sebastian stated repeatedly that if someone does the work it will get accepted.

Then again Pirum should have solved that issues anyways for us :)

(Can't try it from here, will do that tonight)

@sebastianbergmann Thanks for pointing me to the filename

Seldaek commented 12 years ago

@edorian: Pirum 1.1 just means that when you load it via a PEAR repository it will load faster than it did before. The package name should then be pear-phpunit/PHPUnit.

As for having phpunit as part of your requirements, we don't have it yet, but eventually there will be a require-dev section just for that purpose. Only for when you work on a lib, and then having phpunit as part of the deps would be quite nice I think. Having composer support in PHPUnit itself would allow leveraging a few more features than with the PEAR fallback.

I haven't tried installing/running via composer yet, but I think one of the issues someone had was the fact that PHPUnit or one of its dependencies still relies on require_once and the include path to be setup, which just won't work with Composer. Autoloading we can do just fine.

Tatsh commented 12 years ago

@sebastianbergmann 100% in agreement. I install PHPUnit and all related packages (CodeCoverage, CPD, etc) with pear or Portage on Gentoo and all works fine (especially Portage). I have yet to see a need for another package manager. I will also note that I install numerous packages related to PHP (including separate PEAR ones) this way and other libraries for which I have written ebuilds: https://github.com/tatsh/tatsh-overlay/tree/master/dev-php

I know this is a feature of Composer that I have not seen with pear before, but on Gentoo we've had the ability to create new site roots automatically (and even create the settings file for use with web servers) with site-root-based packages (Drupal, phpmyadmin, WordPress etc) for a long time. webapp-config

glennpratt commented 12 years ago

@tatsh that doesn't address dependency hell, which I'm currently in with PHPUnit and different projects. I don't think people are voting to kill PEAR - but installing system level PEARs doesn't have to be the only way to use PHPUnit.

See http://docs.behat.org/quick_intro.html#installation

Tatsh commented 12 years ago

@glennpratt I imagine soon Gentoo will have something like ecomposer.class (just as we have epear.class which greatly simplifies installation) which will be a front-end to composer or similar. Mainly so that an ebuild can simply say to install Symfony-YAML and it will install as it does today, in /usr/share/php (and in all of Gentoo's php.ini files, /usr/share/php is by default in the include_path directive).

I'm not against a non-system-level PEAR or Composer (especially on systems where you do not get root access). I simply prefer system-level installation of packages, and prefer to code against 1 version of a library not several. I also do not want to maintain different versions of libraries for different sites.

Basic example: add a library to a site root at a specific version, and add the same library to another site. Now modify site a's version of the library and now you essentially have two different versions. It may have been necessary to modify for the site at hand (as a last resort) but instead what should be sought after is a library that is useful to both. And it would be safe to assume that the library would be at the same place for both sites in that case. Not only that, but I think this library should never be in the site root unless it absolutely must be (crappy shared hosts which no one should ever sign up for).

PHPUnit is for me no different than other packages. I want it system-wide so that I code against one version and it's always immediately available without worrying about the include path. I find it far easier to have Portage manage things than to manually do so or worry about your PATH variable and so forth.

grEvenX commented 12 years ago

@tatsh well, imho that's a bad practice. If a system administrator updates a library and a user om the server has assumed a version of the library, the entire project can fall apart. If you include the library and version of it in your project (composer.json), you have tested your code against it, and you know that it will work. Upgrading a library can break that.

c33s commented 12 years ago

i often don't understand such long discussions. it's not a decision to go left OR right, it's just ADD option2 to option1.

if someone prefer installing phpunit systemwide via pear perfect, if another person prefer installing different versions application wide via composer also perfect. both is a way to install it, both is ok, both have pros and cons.

but it's an AND not an OR. i really don't see a problem addon one file to the repo, which adds another way to install it.

so please add composer support and don't discuss this topic to dead.

Tatsh commented 12 years ago

@grEvenX I have not had such an issue as I manage most of the systems I am on, or I know what is on them (as any developer should). I do not think we are going to reach a point any time soon where system administrators (such as those who run shared hosts) will install PHP libraries system-wide for their sites hosted, other than some common PECL extensions ((mis)perception that C is safer than PHP). So it is either control the system(s) you have, know what libraries they have and which versions, or include your libraries in the project (site root). The latter is the last resort and is reserved for (bad) shared hosts.

I am not against any of these methods but I prefer the system-wide version as that is one version to remember instead of having to potentially do things like feature test in code (which always slows things down and makes code more complicated). I also do not see why I should keep more PHP code in the site root. I prefer to have the site root minimalist as possible. My deployed site roots do not even have non-minified/compiled CSS/JS files. The old days of everything in the site root (the case for Drupal, WordPress, and even big frameworks like Magento and similar) are gone for me and I am glad.

PEAR is an attempt to make libraries global and I am for it as it reduces duplication (this has many benefits besides saving disk space). Gentoo puts such libraries in /usr/share/php.

PHP is unique in being one of the few big languages right now that really lacks generic libraries and standardisation (and I am aware that the author of PHP specifically implied how he did not want PHP to be 'designed', which I consider a huge problem). When you look at even nodejs or Ruby which are newer than PHP, you can see that things are standardised: installation, how to include, documentation (Python) and documentation standards, and even examples are often provided. And, installation (sometimes optionally) generally makes the library globally available to all code of the same language (npm -g), which is useful. And no, I do not think PSR-* is even coming close to the level of these languages. Rather it is making things far more complicated than necessary (inconsistency in bracket usage, forcing usage of namespaces, and so on).

edorian commented 12 years ago

@c33s

so please add composer support and don't discuss this topic to dead.

Like stated multiple times within this and other discussions:

Once someone does it - it will happen. (I'm also working on it and got some issues fixed along the way) I'm also working on the .phar which will make composer support even easier because with have the same issues.

I can't stop people from commenting and discussion this (and I wouldn't if i could because .. well if people feel the need to do so there surely are reasons) but the roadmap is, hopefully, as clear as it gets.

superdweebie commented 12 years ago

+1 composer. It just works on Windows. Pear is a headache I don't want.

danielholmes commented 12 years ago

Not sure when it updated, but because phpunit pear channel is now on Pirium 1.1.4 you can perform a pear based composer install. In your composer.json:

    ...
    "require-dev": {
        "pear-phpunit/phpunit": "3.6.11"
    },
    ...
    "repositories": [
        {
            "type": "pear",
            "url":  "pear.phpunit.de"
        },
        {
            "type": "pear",
            "url":  "pear.symfony-project.com"
        }
    ]

edorian commented 12 years ago

Thanks for the file @danielholmes. Seems like the recent composer & pirum updates helped.

Full file:

{
  "require-dev": {
        "pear-phpunit/phpunit": "3.6.11"
    },
  "repositories": [
      {
          "type": "pear",
          "url":  "pear.phpunit.de"
      },
      {
          "type": "pear",
          "url":  "pear.symfony-project.com"
      }
  ]
}

php composer.phar  install --dev

Now what, i guess, is left to do is to create a runner that fixes up the include path (or something) for it.

It seems a custom runner wrapper that fixes up the include path would be required for the via-pear install that you'd also have to copy around

danielholmes commented 12 years ago

Yea you're right, I think that might be a change needed in pirium. For the moment I have a phpunit.php file in the root of my project like so:

<?php

$VENDOR_DIR = __DIR__ . '/vendor';

// This should really be part of composer
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/File_Iterator');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/PHP_CodeCoverage');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/PHPUnit');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/PHPUnit_MockObject');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/PHP_Timer');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/PHP_TokenStream');
set_include_path(get_include_path() . PATH_SEPARATOR . $VENDOR_DIR . '/pear-phpunit/Text_Template');
// end of composer

require_once($VENDOR_DIR . '/autoload.php');
require_once($VENDOR_DIR . '/pear-phpunit/PHPUnit/phpunit.php');

And you can run your tests from the root of a symfony project for instance with:

php phpunit.php -c app

Alternatively you can use your project's composer.json "include-path" setting for each of those includes.

b-durand commented 12 years ago

Why PHPUnit should be only for dev? Unit tests and integrations tests must be valid in staging/production environment too !

edorian commented 12 years ago

To restate the current situation because it seems there is a some confusion:

Composer.json directly in phpunit:

If someone is nice enough to do the work needed to get phpunit installed via composer (using composer.json files) we'd gladly merge them. Tagging releases is doable :)

Alternatives:

Until then you can use the script/way @danielholmes provided or have a look at my current try over at:

https://github.com/edorian/phpunit-composer-try

Once I get the feedback that that works out well enough for people I'll see if we can make it "official" and put it in the docs.

antonmedv commented 12 years ago

+1 composer and phpunit.phar.

vadviktor commented 12 years ago

+1 for composer, though I do not wish the pear version to be abandoned as the projects manager likes it. I only wish he would set up a composer.json for the project so we would (composer fans) be able to grab it with our favorite tool. :)

demonkoryu commented 12 years ago

Add another vote for Composer.

fprochazka commented 12 years ago

+1 Composer

pavelkouril commented 12 years ago

Please, do NOT include PHPUnit in Composer.

Composer is for project dependencies (and test framework isn't project's dependency). Only things like frameworks (Nette, Symfony), database layers (Doctrine), etc. should be in Composer. :/

PHP Unit should be IMHO installed system-wide (or globally or whatever you call it).

claylo commented 12 years ago

Composer's PEAR package management is pretty weak. If anyone's interested in pitching in on making this happen (at least interested in helping me test it), I've got it pretty close here:

http://github.com/claylo/phpunit
http://github.com/claylo/dbunit
http://github.com/claylo/phpunit-selenium
http://github.com/claylo/php-text-template
http://github.com/claylo/phpunit-mock-objects
http://github.com/claylo/php-token-stream
http://github.com/claylo/php-timer
http://github.com/claylo/php-invoker
http://github.com/claylo/php-file-iterator
http://github.com/claylo/php-code-coverage
http://github.com/claylo/phpunit-story

You can create an empty directory and put this composer.json in it:

{
    "name": "test/test",
    "require": {
        "phpunit/phpunit": "3.7.*"
    },
    "repositories": [
        { "type": "git", "url": "http://github.com/claylo/phpunit.git" },
        { "type": "git", "url": "http://github.com/claylo/dbunit.git" },
        { "type": "git", "url": "http://github.com/claylo/php-code-coverage.git" },
        { "type": "git", "url": "http://github.com/claylo/php-file-iterator.git" },
        { "type": "git", "url": "http://github.com/claylo/php-invoker.git" },
        { "type": "git", "url": "http://github.com/claylo/php-text-template.git" },
        { "type": "git", "url": "http://github.com/claylo/php-timer.git" },
        { "type": "git", "url": "http://github.com/claylo/php-token-stream.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-mock-objects.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-selenium.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-story.git" },
        { "type": "git", "url": "http://github.com/symfony/Yaml.git" },
        { "type": "git", "url": "http://github.com/symfony/Finder.git" },
        { "packagist": false }
    ],
    "minimum-stability": "dev"
}

Then composer install, require vendor/autoload.php and you're in business.

Still to do, which I'm working on today:

proper installing of files in the bin dir
a post-update/post-install script that applies the replace tasks from PEAR package.xml 2.0
construct modifications of composer.json to a couple of historical branches (last two stable, maybe)

Down the road, I want to leverage package.xml to update composer.json, so that Sebastian and the folks helping him won't have to worry about maintaining multiple copies of the same information.

Finally, I'm going to add composer-related tests to all of my forks too, which hopefully Sebastian will use to feel comfortable with supporting Composer and PEAR.

-Clay

PS: Enough with the upvotes and stuff. Quit whining and help make it happen!

sebastianbergmann commented 12 years ago

Thank you so much for your effort and the "PS", Clay.

vadviktor commented 12 years ago

Thank you Claylo, I will defenitely try your solution/effort out later today! edorian too has a composer try at https://github.com/edorian/phpunit-composer-try, I am still testing that one too. The best would be to be able to have a version that is able to "integrate" phpunit under my project. WHY? Portability, that's why. Everything that has a version number and is being depended on should be under vendor and not installed system wide imho. (at least in my case)

demonkoryu commented 12 years ago

@pajousek We're using PHPUnit's code coverage features as an internal library in a code quality tool. How in the world isn't that a project dependency?

sebastianbergmann commented 12 years ago

@demonkoryu I am curious about your "internal library in a code quality tool". Can you elaborate? Thanks!

demonkoryu commented 12 years ago

@sebastianbergmann Nothing major. I'm creating a wallboard display in my office and want to display coverage diffs for commits where previously covered code becomes uncovered; which is a sign for programming errors and/or dead code. So I'm driving coverage filter manually to drill down the interesting bits.

sebastianbergmann commented 12 years ago

@demonkoryu I would not call that "nothing major". This is along the lines of https://github.com/manuelpichler/php-change-coverage and https://github.com/sebastianbergmann/phpcov/issues/1 -- it would be awesome if you could look into integrating your implementation into the phpcov utility.

demonkoryu commented 12 years ago

@sebastianbergmann Looking into it. It will take some time since I'm doing this in my 5% time.

claylo commented 12 years ago

I've got a version working for PHPUnit 3.6.12.

A couple of notes:

Due to the way composer manipulates include paths, you may have an issue if you already have PHPUnit installed globally. For the purposes of this test, I removed PHPUnit from my global include path.
The file that does the include_path manipulation is located in vendor/composer/include_paths.php.
As you probably know, there are lots of ways to manipulate runtime include-paths. Any one of those methods could allow you to keep a PHPUnit installed globally along with a local installation with a composer-based project. I'll leave that as a an exercise for you, Comment Reader.

The log of my installation and successful run of PHPUnit's own test suite is here: https://gist.github.com/3364287

The composer.json file I used is in the log, but also here:

{
    "name": "test/test",
    "require": {
        "phpunit/phpunit": "3.6.*"
    },
    "repositories": [
        { "type": "pear", "url": "http://pear.symfony-project.com" },
        { "type": "git", "url": "http://github.com/claylo/phpunit.git" },
        { "type": "git", "url": "http://github.com/claylo/dbunit.git" },
        { "type": "git", "url": "http://github.com/claylo/php-code-coverage.git" },
        { "type": "git", "url": "http://github.com/claylo/php-file-iterator.git" },
        { "type": "git", "url": "http://github.com/claylo/php-invoker.git" },
        { "type": "git", "url": "http://github.com/claylo/php-text-template.git" },
        { "type": "git", "url": "http://github.com/claylo/php-timer.git" },
        { "type": "git", "url": "http://github.com/claylo/php-token-stream.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-mock-objects.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-selenium.git" },
        { "type": "git", "url": "http://github.com/claylo/phpunit-story.git" },
        { "packagist": false }
    ],
    "config": {
        "process-timeout": 900,
        "bin-dir": "bin"
    },
    "minimum-stability": "stable"
}

PHPUnit 3.7.x (the main dev-master branch) is also installable. I still need to get the @pacakge-version@ tags, etc sorted out, but am working on that.

Hope you guys find this useful, and take time to try it out.

Finally, Sebastian -- if you'd like to discuss how (or if) to merge this work into the main phpunit (and associated dependency) repository, let's discuss. (Since I modified the 3.6.12 tag to support composer, I don't think a straight-up pull request will be enough.) I'm particularly interested in understanding what you'd consider valid for a test case to make sure the composer installs are working as they should.

sebastianbergmann commented 12 years ago

Yes, I am interested in merging Composer support. My acceptance criteria is simple: PHPUnit should work exactly the same regardless of whether it was installer through Composer or PEAR.

enumag commented 12 years ago

+1 for composer support

sebastianbergmann / phpunit

Composer-like installation procedure, composer.json #522