Using update-alternatives instead of symlinking file

[jonnywilliamson]

Hi Joe,

Was just having a look over the code commits recently and this one jumped out to me.
8309cd3

To switch between php versions we are deleting and creating symlinks all the time. For some reason, (I can't prove it - just feel like) this just seems very slightly risky...and a little bit agricultural!

I then remembered that there was a linux utility that was supposed to do this safely for you -

update-alternatives. I had used it before and forgotten about it, so I took a look at it again.

Here are a few commands to see what it does:
List all the current options for php:

Display detailed info about the php setup

So if you want to do it manually, it provides a very easy menu to switch between php versions:

But of course, we'd rather do it via a command so here's how that would look:

NOTE

When I used the manual "menu" selection above, did you notice the following text:
update-alternatives: warning: forcing reinstallation of alternative /usr/bin/php7.1 because link group php is broken

I had been using the current homestead commands to switch between versions, and that was the first time using this new way to switch them instead. That warning would lead me to believe that the current method of doing this (creating and deleting symlinks manually), is causing some sort of small issue (a link group) and so, re-enforces my belief that perhaps we should be using update-alternatives.

Have you any thoughts?

[svpernova09]

We probably should be using update-alternatives. I used symlinks previously because I didn't want to poke at the system too hard. But we should likely be doing this the proper ubuntu way.

[browner12]

I'm a little confused. We can specify PHP versions on a per-site basis. Why do we need to "switch" versions on the command line?

couldn't we just have the aliases link to the specific php versions, and let php just always link to the most recent?

alias php56="/usr/bin/php5.6"
alias php70="/usr/bin/php7.0"
alias php71="/usr/bin/php7.1"

This way most users can go on normally just using php file-to-run.php, and people who need a specific version can just say php56 file-to-run.php.

[jonnywilliamson]

Those aliases seem seem to have been removed in his commit:

21166d5

[svpernova09]

We want to be able to switch versions on the command line because composer can install different versions of dependencies based on running composer from 5.6 or 7.x

We want to ensure a user with a 5.6 site and a 7.1 site has the ability to swap to the CLI sapi version to run composer with.

[svpernova09]

@jonnywilliamson they were removed in that commit because they were redundant for the functions here:

homestead/resources/localized/aliases

Lines 29 to 42 in 21166d5

	function php56() {
	sudo rm /usr/bin/php
	sudo ln -s /usr/bin/php5.6 /usr/bin/php
	}
	function php70() {
	sudo rm /usr/bin/php
	sudo ln -s /usr/bin/php7.0 /usr/bin/php
	}
	function php71() {
	sudo rm /usr/bin/php
	sudo ln -s /usr/bin/php7.1 /usr/bin/php
	}

[jonnywilliamson]

@svpernova09 sorry Joe, yes I had seen and understood that already.

My message was for @browner12.

If I get a chance/its something you think is useful, I can make a PR over the next few days. It's only a small change.

[browner12]

@jonnywilliamson well, we can do them as functions or aliases. doesn't matter either way to me.

@svpernova09 ahhhh, i see. that kinda sucks. from what I just read it seems like running php56 composer update works okay, but then possibly fails later on because it is running php again

[svpernova09]

IMHO it's up to the developer to know that they should be running composer on a specific version of PHP if they're using PHP versions per site. If symlinking isn't breaking anything I'm fine with it. If there's a proper "Ubuntu Way" lets investigate

[browner12]

could someone with a PHP 5.6 project test out the following command for me? i have nothing to test it on unfortunately.

cd into your project and run:

/usr/bin/php5.6 /usr/local/bin/composer install

This should run the composer phar with the PHP 5.6 interpreter.

Make sure PHP 7.0 or 7.1 is currently linked to php

[browner12]

ok. lots of digging today. hopefully moving towards a solution. confirmed with @Seldaek that composer will use the version of PHP that it was called with. you can see this with the command

composer show -p

The shebang in composer.phar is #!/usr/bin/env php, which is our default PHP installation (currently 7.1). We can override that by specifying our interpreter.

/usr/bin/php5.6 /usr/local/bin/composer show -p

This makes me think we can just go back to using the aliases, and avoid the deleting and recreating of the symlinks.

alias php56="/usr/bin/php5.6"
alias php70="/usr/bin/php7.0"
alias php71="/usr/bin/php7.1"

The only thing that kinda sucks is because we are no longer using composer as the interpreter, we need to pass the actual file path.

php56 /usr/local/bin/composer
php70 /usr/local/bin/composer
php71 /usr/local/bin/composer

Just thinking out loud here, we could maybe solve this by leaving them as functions instead of aliases, and saying if the first parameter you pass is "composer", we will automatically resolve it to this format.

function php56() { 
    if $1 == 'composer'
    then
        /usr/bin/php5.6 /usr/local/bin/composer $@
    else
        /usr/bin/php5.6 $@
    fi
} 

This is back-of-the-napkin. I know it's not quite right.