Drop HHVM support? #18922
Comments
|
We used to do that but just switched to PHP 7 recently. |
|
I think the main question is HHVM vs PHP7. Some projects switched to HHVM before PHP7 was announced but I haven't heard of any significant move since the announcement of the PHP7 speedup initiative. Note that we don't spend too much time on HHVM support and we don't have too many hacks to support it either. |
|
To me, HHVM was a nice start for php7, but that's about it. Hacklang is a completely different language now so someone using symfony will never be able to use the speed of HHVM to its full potential with Symfony. When supporting HHVM you might even be unable to use some newer php versions if the support is not backported to HHVM properly. Making it work on HHVM takes a lot more effort and knowledge of what is and what is not support. To be honest, I'm not even looking at failures in HHVM anymore when contributing. |
|
Sad truth indeed. We'll probably end up dropping HHVM support as well, unless it gets in sync with PHP 7 :-\ |
|
The question is what the level of effort is to be HHVM compatible. Obviously using HHVM-specific features is a no-go, at least in the core system, but if it's a marginal effort, great. If it's considerable effort, not so great, and probably not worth it now that the performance difference is basically a wash with PHP 7. Why is Travis still running an old version? Could they be coaxed to upgrade? |
|
in my point of view hhvm is not a thing in the community nor in the industry. Symfony can safely drop hhvm support like many others packages / components. |
|
Travis runs an old HHVM (3.6.6!!!) because of dependencies with newer versions that are not available with their ancient Ubuntu version. |
|
The problem is that HHVM is not properly tested right now. If HHVM must be supported, it should be properly supported, i.e. against different versions of HHVM as it is done for PHP. If someone is using Symfony with HHVM and needs something to be fixed at some point, unless it's a very ugly hack I hardly see a reason to fix it if it's reasonable, but it may not be worth to promise a real support either. |
|
Travis-CI did an update recently that allows using newer HHVM versions, see travis-ci/travis-build#733 and https://docs.travis-ci.com/user/languages/php#HHVM-versions Unfortunately it's not as straight forward to set up as the main PHP releases. |
You can run whatever hhvm version you like by using docker containers on Travis. |
|
@rybakit Of course, but we are trying to figure out if it's worth the effort. |
|
@mbabker but the container infrastructure (used by Symfony) still runs on Precise for now, meaning that newer versions of HHVM are not available (as Facebook dropped support for Precise a long time ago) |
|
I would agree with @omansour. In our case hhvm is out of scope in our projects |
|
@stof Unless there are explicit dependencies on the Precise structure (I'm not well versed in the CI configs), you can specify the distro on a per-build basis so all existing tests would still run on Precise and HHVM tests could run on Trusty. Personally I've got no opinion either way, but I've got a contributor on a project who has been doing work on HHVM compatibility so I'm aware of that change through his efforts only. |
|
Many third-party projects are using Symfony components. For instance, there is https://github.com/php-pm/php-pm with multiple dependencies on Symfony packages. I'd like HHVM implementation to be closer to PHP and I even contributed few patches, especially for Phar support. If there will be some push from community in terms of decreasing incompatibilities an effort to keep HHVM support might become much smaller. At the end of the day, HHVM have already influenced PHP itself in a good way. If it will be around, even though diverged from PHP, it is better than having single PHP interpreter in the wild (I'm looking at Symfony as one of top projects in PHP ecosystem which this way or another influences everything else). |
|
I think maintaining HHVM is reasonable if it's not too much work. HHVM is going forward separately from PHP 7 and who knows what they manage to do in the future. |
|
it would be great if they could implement feature parity with PHP 7 though (they currently target PHP 5.6, with some differences). |
|
I think if we are not able to provide HHVM test suite without huge effort it's better to drop than say we support it BUT .... |
|
I have an idea to try something on Travis to get access to their new HHVM multi-version support. Will report back this evening whether it works |
|
In my opinion as maintainer of a project that uses Symfony components, breaking changes on HHVM would lead to me dropping HHVM, not dropping Symfony components. |
|
@ciaranmcnulty well said |
|
To be clear, Symfony keeping HHVM support is still the best option for lazy me but if you drop it it won't be a huge impact |
|
I would say we should push on travis to update trusty env (or maybe they will switch to 16.04 instead soon, who knows, they dont tell). So tests can run on lateste hhvm version, it is still relevant for some, and they might further improve its performance as well. |
|
HHVM supports the new features of PHP7 since version 3.11. Backward incompatible changes can be activated via special php.ini parameters. |
|
We use hhvm with symfony on production. However we still testing for 5.6 and 7.0 too and hhvm 3.6.6 |
|
It could always be an option to add the HHVM matrix to the list of allowed failures, but that means that not everyone will fix it. It could be an incentive for other people to contribute HHVM specific PRs to symfony if they want to get it to work. If this doesn't happen, support can be 'safely' dropped. |
|
HHVM parity with PHP HHVM vs PHP7 HHVM speed and hacklang
|
|
Nice comment @DaRamirezSoto. Agree for PHP 5.* vs HHVM performance. But PHP 7? For some articles I saw, The performance looks like to be the same or maybe better for PHP 7, maybe I'm wrong. In a more personal case, I do not use HHMV at all. @fabpot I also launch a poll on Sonata for HHVM usage. This could give you more information: sonata-project/dev-kit#126 For the moment, it seems to not be used. |
|
@DaRamirezSoto Wordpress is still supporting (and has to support) php 5.2, so I don't think it would be using that many features which could be or are bugged in HHVM, or under-performing for that matter. |
|
Bear in mind that Hacklang and Php can be used together at the same time. In a well-designed system, you can decouple business logic components and write them in Hacklang strict mode. Code written in Hacklang strict mode gains performance boost and powerful static typechecking. |
|
@soullivaneuh I don't think that decision should be based on which of the the 2 preforms best. Both preform well enough to be used and both have their merits. Even though the adaptation of HHVM might seem low at current time. I do feel that it is going to shine more in enterprise realm for the obvious reasons. Facebook needed to develop it to help them cope with issues which they where having at much larger scale. Would Symfony not benefit from being able to be used on such platforms? @iltar Yes wordpress can be used on 5.2 but nobody in their right mind would do this since php 5.5 nearing EOL. So it pretty much only gives strength to my argument that symfony code quality is higher and should be able to be run in HHVM. |
|
Given that I managed to use the uptodate HHVM version on Travis (see the PR referenced just above this comment), I vote for keeping the HHVM support. |
@nicolas-grekas @fabpot Maybe start a Twitter/GitHub poll to have a clearer view? |
This PR was merged into the 2.7 branch. Discussion ---------- Run an uptodate version of HHVM on Travis | Q | A | ------------- | --- | Branch? |2.7 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | n/a Using th EB23 e Trusty infrastructure allows running an uptodate version of HHVM rather than running the latest version supporting Precise, which is very old. It relies on an undocumented feature of the Travis config file, namely the fact that ``matrix.include`` actually allows to overwrite everything from the config file (it is merged with the main config), even though the Travis linter complains about it. I think it is fine to use this and to replace it with an official approach once there is one. Refs #18922 Commits ------- e6956c9 Skip some tests on HHVM due to a PHPunit bug e041da0 Use the Trusty Travis infrastructure for HHVM builds
|
Thanks to @stof we're now testing the latest HHVM and it's green. |
* drop hhvm (see symfony/symfony#18922) * test on php 7.1 * test on sf 2.8 stable, sf 3.3 stable and 3.4 dev
I'm wondering if anyone is using HHVM to run Symfony apps?
Travis only runs legacy HHVM, which means we do not verify that Symfony really works on current HHVM.
The text was updated successfully, but these errors were encountered: