-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert back to requiring php 5.6 as the minimum php version #2665
Conversation
I think we'd need to change Drupal VM's default version of PHP, or else somehow enforce a composer platform requirement of PHP 7 when Drupal VM is used. https://github.com/acquia/blt/blob/9.x/scripts/drupal-vm/config.yml |
Also need to change PHP version in: |
Ahh yup yup, I've gone and made those updates. I didn't see anything else in a search/replace for 7.1 or 7 although that had a lot of noise. We'll see what travis thinks ;) |
@@ -788,7 +788,7 @@ public function issueEnvironmentWarnings($command_name) { | |||
* @throws \Acquia\Blt\Robo\Exceptions\BltException | |||
*/ | |||
public function warnIfPhpOutdated() { | |||
$minimum_php_version = 7; | |||
$minimum_php_version = 5.6; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not keep a warning in here, but don't throw an exception? Maybe suggest users to move off 5.6 at their convenience...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, have a warning and suggest users move to 5.6 if they really need it, but not encourage it as a default. Otherwise, this entire issue feels like a step backwards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is not currently a warning but rather an exception, causing BLT to fail. I agree -- giving some warning that you're running 5.6 would be good, although Drupal already does that.
.travis.yml
Outdated
@@ -3,7 +3,7 @@ language: php | |||
dist: trusty | |||
|
|||
php: | |||
- 7.1 | |||
- 5.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it possible to test with both versions? via the matrix? I don't know enough about it, but just seems like it would be worth considering.
Weird, the last build exited prematurely. It's a false positive.
Somehow this has exposed and triggered a bug in the exit_early script. |
Cleared caches and restarted builds. |
Passing. However, I'm still not convinced that this should be merged. Can we continue the conversation here? #2661 I would like to understand what the blockers are for updating to PHP 7, and also why extending LTS for 8.9.x is not sufficient. |
scripts/travis/.travis.yml
Outdated
@@ -1,4 +1,4 @@ | |||
sudo: true | |||
sudo: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to update line 6. Also, is this sudo change necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 6 of this file also needs to be 5.6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed! I also added a doc comment to advise the user this should match whatever version their prod environment is in.
@@ -74,7 +74,7 @@ npm_config_prefix: "/home/{{ drupalvm_user }}/.npm-global" | |||
installed_extras: ${installed_extras} | |||
|
|||
# PHP 7 | |||
php_version: "7.1" | |||
php_version: "5.6" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geerlingguy Are more changes than this required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No not for the VM... but do we really want to default to 5.6? Shouldn’t we default to whatever Acquia Cloud currently defaults to (7.1 IIRC)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trouble is that if your host is 5.6 and your VM is 7, you get some issues with Composer. Maybe we should look into defaulting the "config" in composer.json to PHP 7. I know that adding it to template/composer.json
and composer.required.json
do not work. We'd need to actually modify the generated composer.json
after project creation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually run 5.6 on host and 7 in VM. TBH, I haven't really had a problem with it... I usually run $ composer
commands on the host, and BLT will run composer in the VM... knock on wood but I haven't seen much yet. Just wanted to share... ha.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you use the platform config setting in composer.json?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most people I've seen (including myself) run a higher PHP version on the host than the VM. i.e. 7.2 on the host, and 5.6 or 7.1 in the VM. The reason being pretty obvious, that the VM replicates an Acquia Cloud or other hosting environment that generally lags behind general desktop software in terms of PHP releases.
I'd really like to see the VM default to the highest version possible in order to match the host machine, or at least never be "behind" the host, which leads to some nasty problems. For instance, running composer update
on the host breaks everything by pulling in 7.1 dependencies that won't run in the VM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you use the platform config setting in composer.json?
I don't. I mean, below is my output, haha. I haven't upgraded my host b/c I've just been lazy, TBH, and I haven't seen a need to. I do a lot of composer updates for our project too, and just haven't run into any issues...
If you need me to try anything out, LMK - I'm happy to report back.
$ php -v
PHP 5.6.31 (cli) (built: Aug 17 2017 16:41:40)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.5.3, Copyright (c) 2002-2017, by Derick Rethans
$ vagrant ssh -c 'php -v'
PHP 7.0.20-2~ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jun 14 2017 05:33:01) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.20-2~ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.5.0, Copyright (c) 2002-2016, by Derick Rethans
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe b/c my VM is 7.0 instead of 7.1? I really need to update both my host and my guest, haha.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm IMHO, except for grabbing the initial code you really should never run composer on the host environment. The part that matters here is that your VM matches your Production environment. If I could have my host not have ANY dev tools (php, drush, composer, etc) I would.
While Acquia Cloud -defaults- to 7.1 for new instances, it certainly isn't what most of our clients are running. And until ACE+ACSF are fully off 5.6, we shouldn't be shipping a VM that can break prod.. which is the whole point of Vagrant in the first place. Since 7.0 much more backwards compatible with 5.6 than visa-versa, we need to use the least common denominator.
Pinging @danepowell for visibility. |
scripts/travis/.travis.yml
Outdated
@@ -25,6 +25,7 @@ cache: | |||
- "$HOME/.drush/cache" | |||
- "$HOME/.npm" | |||
- "$HOME/.nvm" | |||
- "vendor" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why add this back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just reverting the changes associated with php7, if this wasn't meant to be part of that commit (or was two commits in one), then this should be taken out of the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not add it back.
…cquia#2665)" This reverts commit f43c708.
This reverts back all the php7 changes that was performed after beta3 was released.
Note: We should be documenting that if you're using php7 locally, you'll need to manually update configuration files to support php7. While its unfortunate that we support both versions of PHP, we must continue to do so until our product roadmap makes it EOL, which is slated for the end of 2018.