dev-php/twig should contain a twig.so PHP module, but on Gentoo it does not. cf. http://twig.sensiolabs.org/doc/installation.html#installing-the-c-extension Reproducible: Always
Created attachment 417986 [details] twig-1.23.1.ebuild I wrote an ebuild for the new version that installs the C extension, but I don't use twig, so caveat emptor. I have bad news though. Upstream is going to remove their autoloader in the 2.0 release (it's already gone from master), intentionally breaking your ability to install twig through your package manager: https://github.com/twigphp/Twig/blob/1.x/lib/Twig/Autoloader.php Sooner or later, you're going to have to switch to composer unless they reverse that "short-sighted" decision.
(In reply to Michael Orlitzky from comment #1) > Created attachment 417986 [details] > twig-1.23.1.ebuild > > I wrote an ebuild for the new version that installs the C extension, but I > don't use twig, so caveat emptor. Thanks a lot! > Sooner or later, you're going to have to switch to composer unless they > reverse that "short-sighted" decision. Can Composer be used to load system PHP classes? So that the C extension and compatible PHP classes can still be managed by the package manager? Because I don't see how they (Twig guys) are going to convince webserver admins to load binary PHP modules that an arbitrary user compiled and placed on their server...
(In reply to Dennis Schridde from comment #2) > > > Sooner or later, you're going to have to switch to composer unless they > > reverse that "short-sighted" decision. > > Can Composer be used to load system PHP classes? So that the C extension and > compatible PHP classes can still be managed by the package manager? Because > I don't see how they (Twig guys) are going to convince webserver admins to > load binary PHP modules that an arbitrary user compiled and placed on their > server... It's a weird story, but the answer right now is "I've tried and haven't figured out a way to do it." With C extensions, you're SOL. I found these pull requests, * https://github.com/composer/composer/pull/2898 * https://github.com/composer/composer/pull/3897 but for now composer doesn't do C extensions. And when it does, it probably won't play nicely with our slotted PHP that you can switch on-the-fly. For the pure-PHP code, it might be possible eventually. Everyone is switching to autoloaders for their PHP classes these days (for reasons I can't imagine). So far so good, but then composer came along, and when you install a package with composer, it generates its own vendor/autoload.php for *your* package. As a result, everyone who has switched to composer thinks "why should I keep our autoloader around if composer generates one anyway?" So they delete their autoloader, and now the source package is broken out-of-the-box and will only work if you install it with composer. Right now, if we install a composer-only package with an ebuild, it will be missing the vendor/autoload.php file and nothing will work because upstream deleted all of its "require" statements. So.... how to fix it? We need composer to generate the vendor/autoload.php file, but we can't just use composer from within the ebuild, since that would violate our sandbox (and break a bunch of rules). What we need from composer is, * The ability to tell it to do a global install to a specific directory like /usr/share/php/<package-name>. Not possible last time I checked. * The ability to install from a local tarball without using the network, so we can tell it to install from $DISTDIR. I think this is possible, but we'd have to mangle upstream's composer.json to do it. Then if someone wants to wrap all that in an eclass, we'd have a start.
This is in v1.29 now, but only for php:5.6 (that's what upstream supports) and behind USE=extension. Some optimism: the Fedora guys created an autoload thingy that works like the one that Composer generates. We're now able to package things that would otherwise require Composer, and all we have to do is ship a little script that invokes the Fedora autoloader with the right dependencies: https://wiki.gentoo.org/wiki/Composer_packaging We should be able to keep Twig-2.x working that way.
