I'd like to have this keyworded on the remaining arches, but not while we're using the phar releases. The source releases are on github: https://github.com/sebastianbergmann/phpunit/releases The phar that we install bundles all of its dependencies -- about fifteen packages copy/pasted into that one file. Debian manages to do it, https://packages.debian.org/sid/phpunit so we should be able to, too. And some of the dependencies are available in Gentoo already: * dev-php/File_Iterator * dev-php/PHP_CodeCoverage * dev-php/PHP_Timer * dev-php/YAML * dev-php/Text_Template
I was just thinking about this again. Debian already has all of the dependencies for PHPUnit packaged, and they've unravelled the composer mess for PHPUnit as well as its dependencies. Maybe it makes sense to switch to the Debian tarballs as our SRC_URIs? That would let us package the dependencies of PHPUnit easily, and then their PHPUnit should work out-of-the-box.
Hi there, I started working on it, I hope it will be easier now that I can rely on the composer packaging experience, but there still quite some work to do. About the packaging itself, I have some feedback already : * On the tests, most of package that get tests, but most of the time, they come with new dependencies (specific for test), and this go on for a while, I try to go to the end of branch by it take a lot of time, should I limit to run the test of only the first level dependencies ? * How can we run the test suite (for phpunit itself), if it *require* phpunit to run :) ? * There also a strange bug for phpunit / phpunit-mock-object in the tarball the 'composer up' won't work, but work in the git tree (issue here: https://github.com/sebastianbergmann/phpunit-mock-objects/issues/342 ). Guillaume
(In reply to Guillaume Seren from comment #2) > > About the packaging itself, I have some feedback already : > * On the tests, most of package that get tests, but most of the time, they > come with new dependencies (specific for test), and this go on for a while, > I try to go to the end of branch by it take a lot of time, should I limit to > run the test of only the first level dependencies ? If you are going to be maintaining these packages for a while, you can always add the test suites at a later time. I would suggest getting everything in the tree, and then trying to enable the test suites one-at-a-time, starting with the ones that are easiest. I don't think it makes sense to add a bunch of packages (creating more work) solely to run test suites. Once an unbundled PHPUnit is in the tree, it will be obvious how much extra work is needed to add the test suite to each of its dependencies, and we can make a more informed decision then... > * How can we run the test suite (for phpunit itself), if it *require* > phpunit to run :) ? You can't, at least not in the usual manner. Two ideas: 1. You could implement the test suite, but then set RESTRICT=test in the ebuild. This lets *you* test the package after an update, but prevents circular dependencies for end-users. 2. You can add upstream's phpunit.phar to SRC_URI, conditional on USE=test. Then, you can use the phar file to run the test suite, and afterwards, just throw away the phar file. (If this works, I like it better.)
Hi there, I have worked more on the phpunit packaging it is coming pretty well, I miss only a few package on the list, so I hope finish it soon. (In reply to Michael Orlitzky from comment #3) > > I don't think it makes sense to add a bunch of packages (creating more work) > solely to run test suites. Once an unbundled PHPUnit is in the tree, it will > be obvious how much extra work is needed to add the test suite to each of > its dependencies, and we can make a more informed decision then... Yes about that there also some author who don't want to package the tests in the release tarball, fedora work around that by re creating a complete tarball from the sha1 of the release [1], but in the gentoo case I think we should stick with official release and so package it without test and ask them if it is possible to maybe add them later [2]. I have one other strange case, the libs that didn't have namespace declaration, like 'phpunit-php-timer', I have 2 choices: * Not adding an autoloader like fedora does [3]. * Adding an autoloader, and create an according autoloader, that way every package get it's own autoloader, so it works the same to load. * Maybe there is also the option, of generating an autoloader, without namespace, I am not sure. [1]: http://pkgs.fedoraproject.org/cgit/rpms/php-myclabs-deep-copy.git/tree/makesrc.sh [2]: https://github.com/myclabs/DeepCopy/issues/58 [3]: http://pkgs.fedoraproject.org/cgit/rpms/php-phpunit-PHP-Timer.git/tree/
First of all Happy New Year ! Well I pushed forward on the classmap case [1], talked about that with Remi from fedora helped, but it bring a new case: To solve the classmap loader we need to add a new package that provide phpab, to package it it need 'itself' to generate the autoloader for it's dependencies [2]. So it is pretty much the same case than running the tests for phpunit without having it installed, so I see 2 options: * Generate the autoloader on my machine, its less dynamical but it is also simpler. * wget the phar file, more generic option, also fixes the phpunit test case, then use the phar to run the tests or generate the autoloader, it's a bit more complex to make but I think, it could be the best option. [1]: https://github.com/php-fedora/autoloader/issues/15#issuecomment-269812805 [2]: https://packagist.org/packages/theseer/autoload
Hey, I decided to stay simple, for the moment so: * I use a local version of theseer-autoload, to generate the needed autoload files. * So I commit them in the tree with the ebuild, these are not too big, and quite easy to debug. * If I need more than 1 lib I just require_once, the other libs needed in the autoload. I think this process is simple and easy, and I'll stick to it for the theseer-autoload and deps so this way we won't need it to install itself. For the other packages that might need a classmap loader I will check if it is better to generate the autoload on install or to stay with that process.
I have just posted dev-php/phpunit-5.7.15 and unbundled the dependencies
Hey @grknight ! Thanks for helping me pushing this, it was a lot of work to do on my own, and I have putted it aside while I have been working on the composer-1.3.2 with tests, (here https://github.com/gentoo/gentoo/pull/4010). While I am happy that you helped pushing this work on the tree I was a bit surprised to see you did it without me :/ I am glad to have helped to push this upgrade of the package, and I don't take it wrong but I wanted to share my feeling, because I put quite a lot of time into it (and composer before).
