Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

allow parallel version installation? #8

Closed
lotia opened this Issue · 40 comments

8 participants

@lotia

Would folks consider allowing parallel versions like the versions folder in homebrew-alt so it is possible to have multiple versions installed simultaneously and switch between them using brew link and brew unlink. While such a mechanism wouldn't allow the two versions to be used at the same time, it would make it possible for users to switch between significantly more easily. Thoughts?

@josegonzalez

I would rather this be a part of homebrew proper[1], but I'm open to discussing the matter. I think it would be difficult to maintain multiple PHP brews, whereas having one means we can test all changes against any of the builds.

[1] https://github.com/mxcl/homebrew/wiki/Wishlist,

@lstat

This doesn't solve the problem in Homebrew but, you may be interested in phpenv and php-build for managing multiple versions.

@josegonzalez
Owner

Now that PHP54 is here, this might be a nice feature. PHP54, PHP53, PHP52. Hmmm.

@phoenixsong6
Owner

We could emulate homebrew-alt's 'versions' directory, and leave alternate php formulas with just the stable (remove head and devel).

@lstat

If going the multiple version route, changing the php.ini path and config file scan dir to be prefixed under the php formula would make sense. This would be good for head and devel builds too.

@mkalkbrenner

Don't forget the "phpized" additional modules and pecl stuff.
formulae like apc.rb need to be compiled for all php versions, right?

@josegonzalez josegonzalez referenced this issue
Closed

5.4.0 #13

@josegonzalez
Owner

@mkalkbrenner Yeah, that would definitely be a concern. People wouldn't want to have to recompile formula etc. when switching between php versions.

Not sure what the best solution is here, since we are somewhat unique amongst programming languages in how dependencies are managed. Does anyone know what python does in these cases? I know ruby has gems, and it's easy to handle with rvm.

@lotia

@ampt I wonder if it could be managed by abusing symlinks for the current active version? Or if the idea is to truly allow multiple versions to be installed and used simultaneously, then I don't have a great solution.

@lstat

@josegonzalez Python has virtualenv and virtualenvwrapper to handle isolated Python environments much like gem sets in rvm. Although it does not seem to handle the installation of multiple versions of Python. I guess that is left up to the user or something like Homebrew.

@lotia That could work using brew switch which attempts to switch between versions of a formula. This is assuming that you could install PHP 5.2, 5.3 or 5.4 from the one formula. If each version of PHP was in a separate formula (php52.rb, php53.rb, etc) then you could just brew ln php52, brew unlink php53 to switch between versions.

If you use pecl to install extensions (apc, etc) then they are prefixed under PHP, or whatever the ext_dir is set to in pear config. That way you can manage your extensions for each version of PHP you have installed.

@phoenixsong6
Owner

With the way that PHP handles its extensions, I think it's a bit beyond the scope of homebrew to support the modules across multiple versions. It should be enough to provide stable formulas for the different versions, and we can leave it to the users to brew (un)link ... to switch, and phpize and ./configure ... for the module support across different versions.

@eveiga

@josegonzalez Take a look at pythonbrew (https://github.com/utahta/pythonbrew). This should give you a hint on how to handle multiple installations of python versions and how to switch between them in an easy way. This is equivalent to ruby's rvm. Then, like @ampt said, you have virtualenv (virtualenvwrapper is a great tool that depends on virtualenv) that allows you to create isolated python environments, but always based on the local installed python versions!

Touch if you need some help!

@josegonzalez
Owner

@eveiga Unfortunately, this is for PHP, not python, so the solutions there aren't really going to work without some major hax against homebrew I think.

@eveiga

Also, I've found this project: https://github.com/c9s/phpbrew

Apparently this guy is doing some great stuff regarding the issue of handling multiple php installations (Sorry if this is somekind of repost).

@josegonzalez
Owner

I think maybe we just want to have multiple PHP formulas, and let something else handle swapping between them. Don't know what directory structure we would use, so if someone has time and wants to experiment with this, that would be great.

A small issue would be making sure the php.ini file is always forwards and backwards compatible.

@phoenixsong6
Owner

We could use separate formulas and configure php like

# args
"--with-config-file-path=#{etc}/php.d/#{version}",
"--with-config-file-scan-dir=#{etc}/php.d/#{version}",
...
# FPM
touch "#{var}log/php-fpm-#{version}.log"
...
# Installation
("#{etc}php.d/#{version}").install "./php.ini-production" => "php.ini" unless File.exists? "#{etc}php.d/#{version}/php.ini"
...
# FPM Installation
("#{etc}php.d/#{version}").install "sapi/fpm/php-fpm.conf"
inreplace "#{etc}php.d/#{version}/php-fpm.conf" do |s|
...

Above code untested (just wrote it), but I think that's the general idea. The directory structure is a bit verbose, but in this case that might be a good idea just so we can keep the versions clear.

@josegonzalez
Owner

How do we want to handle extensions? Does it make sense to do the same for those?

We could do something like

Formula/
    # php tools that don't depend upon a version
php52/
    php52.rb
    gearman-php52.rb
    # other php52 specific stuff
php53/
    php53.rb
    gearman-php53.rb
    # other php53 specific stuff
php54/
    php54.rb
    gearman-php54.rb
    # other php54 specific stuff

Thoughts?

@phoenixsong6
Owner

The modules are usually customized for a specific php version. That's more or less the entire purpose of phpize.

The problem we will likely face is that homebrew only allows one installation of each formula, end if we force the install, we'll have leftovers when we uninstall.

On the other hand, like your diagram above, we could have an instance of each module for each version which seems somewhat crazy.

In my opinion, our solution lies in the usage of git. We could either keep multiple branches to keep track of each version, or if we know that no more changes will be made to a particular version, leave a tag of the previous version before updating the formula.

This will allow us to do something like:

git checkout PHP53
brew install Formula/php.rb
@lotia
@josegonzalez
Owner

@phoenixsong6 Maintaining multiple branches would be annoying, and confusing to users.

@lotia PHP is weird since sometimes getting PEAR/PECL installed with the proper perms does not quite work. I know thats why I use homebrew to handle extensions. In this case, using multiple folders works well if we keep them with that naming format. Extensions aren't linked to outside of the brews, and in your php.ini, and if we use the php-version in the path to the current ini, then we can probably divide out the environments. At that point, it's a matter of telling the user to make the change in their apache conf to use whatever php they want.

In fact, we could make it such that there was a tool to switch your php between major versions. I don't think we should have to support minor releases, so no need to have more than 3 release folders for now. As far as testing new extensions across versions, thats not such a pita that I can't do it when merging in new brews.

@lstat

Another option could be adding an external command into Homebrew that works the same as brew versions but for external repositories.

Currently in Homebrew to install a particular version of git you run brew versions git to get a list of all the versions of git along with the command to checkout that particular commit for git.rb.

This new command lets call it versions-ext for now, would be run something like brew versions-ext /path/to/homebrew-php php. The only difference is that we pass in the path to the external git repo we want to search for versions of a formula in (homebrew-php).

A external command like this could be useful to other external Homebrew repositories like homebrew-alt.

@josegonzalez

That introduces much more complexity than needed. I think it will be easy to maintain multiple versions of the brews in different files, and also allow us to pinpoint what exactly is broken and where. I'm going to work on this tonight in a separate branch, and make the pull request soon. If you have alternative ideas, I suggest you implement them and we go from there.

One thing I don't like is maintaining multiple homebrew-php branches, one for each php version, nor multiple homebrew-php forks, one for each php version. Both sound like terrible ideas from a maintenance standpoint.

@wilmoore

FYI, I maintain php-version which also does version switching (actually, that is all it does). It would be awesome if you'd take a look and see if it fills a gap pertaining to this issue (I think it does). I'm happy to add useful features that would help this effort and/or take pull requests :)

@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez

Had time to play around with this, please check out the php-versions branch to see how it works.

There can only be a single folder in tap'ed repositories, hence the new namespacing. You'll need to manually update your existing brews, sorry.

This also maybe allows us to support php52. I'm hesitant to do so, but at least we could.

As far as extensions go, going forward I think it makes sense to let someone create an extension for their flavor of php, and then I would simply test it against the other versions available in homebrew before merging it in.

Thoughts?

@josegonzalez

Branch available here: https://github.com/josegonzalez/homebrew-php/tree/php-versions

It is not to be merged in until I get some feedback.

@wilmoore

Hi @josegonzalez

Nice work. php-version has an updated formula: https://raw.github.com/gist/1702891/php-version.rb

@josegonzalez

@wilmoore pull request!

@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@lstat

One thing that comes up for me is that the php.ini and php5/conf.d are not namespaced. This is a problem when installing extensions and enabling them in php.ini since 5.3 and 5.4 have a different API version and extensions need to be compiled against the version of PHP you are using them for.

We could prefix the config files like so:

/prefix/etc/php/5.3/php.ini
/prefix/etc/php/5.3/conf.d
/prefix/etc/php/5.4/php.ini
/prefix/etc/php/5.4/conf.d

What are peoples thoughts on this? Do many people intend on using 5.3 and 5.4 side by side?

@wilmoore

Do many people intend on using 5.3 and 5.4 side by side?

Being limited to a single major versions seems like an arbitrary and unnecessary limitation.

+1

@josegonzalez

Seems legit. I can take a look at it later tomorrow, unless someone has a quick patch they can throw in a gist here for the two formulae.

@lstat

Quick patch for both formulae.

@lstat

Also there was a problem with patches in the php54 formula I've added this in a separate gist

@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez

Commits amended. Thoughts?

@lotia

This seems like a pretty neat way of allowing multiple php versions to coexist within homebrew. Thanks all doing the work required. I feel a bit sheepish for having proposed it and then not having done anything towards it.

@josegonzalez

Only took three months for me to have an afternoon to work on it ;)

@josegonzalez josegonzalez referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@josegonzalez

@bobthecow thoughts on this? I think this is something you'd want to follow, and want to get it right before I merge this in.

@josegonzalez

Merging this in because we want 5.4 out there :)

@josegonzalez

Closed by eba616c

@clintonpaquin

Any bump on this? looking to install php52 to run on a legacy site

@wilmoore

For those that land here wondering if this issue is resolved, it is. php-version automatically picks up PHP versions installed via homebrew:

Thanks to everyone involved for getting things working smoothly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.