What is the scope for phpenv-virtualenv

[nickl-]

This said offlist by @ramsey, (paraphrased ever so slightly)

Our primary goals are to be able to separate out the include paths and extensions used for various projects. Currently, most people use different VMs to accomplish this, but we think it would be great to be able to use the same machine and to use "activate" and "deactivate" commands (like with virtualenv) to set up and "tear down" your PATH, so that you're potentially using a different PHP with different PEAR and PECL extensions, as you switch from project to project on the same machine.

We phpenv is complementary to this, since it provides the ability for the user to easily build their own different version of PHP, placing it into their home directory, without any need for super user access, but we do think there's still a need for a project that differs from phpenv. With phpenv, the user will be able to build one "central" PHP 5.3 binary, for example. With phpenv-virtualenv, they will be able to create a "virtual" environment that wraps the PHP 5.3 binary they installed with phpenv (or the system PHP, if they choose), and then it will separate it out into its own "virtual" environment, where PEAR and PECL libraries will go separately from the "central" library in their ~/.phpenv/versions directory. They could essentially reuse the same PHP 5.3 binary with multiple projects that use multiple versions of PEAR and PECL extensions.

@ramsey and @jwoodcock have discussed ideas for something more than phpenv and they get a +1

[nickl-]

a PHP environment would be dependent on its own php.ini configuration file and this is the bare minimum requirement to facilitating this. Agree?

PHP extensions can be built into the PHP binary but manual extensions built with phpenv or downloaded and installed via PECL are still bound to the specific binary distribution as well, you cannot use an extension built for PHP 5.4.1 on PHP 5.4.2 for example. This is not a problem though, because it doesn't matter what extensions are installed as only the extensions that are explicitly enabled by its php.ini will be active for any given PHP environment. So no need to bother relocating PECL extensions outside of their default location.

PEAR libraries or other PHP libraries like those provisioned by PHYRUS or composer on the other hand has a slightly larger range of compatibility. These should remain functional for any given major release version of PHP ie 5.4.x or 5.5.x. I have actually given it some thought to have phpenv install a common PEAR Directory (as per pear config-get php_dir) to service each major version and in so minimize the current requirement of having to install these libraries separately for each release which is unnecessary. This may be something to keep in mind in the virtualenv scope.

While PEAR installs libraries globally, composer on the other hand has adopted the convention of "locally" installing their libraries into the vendor directory located off the root of a project's folder. PYRUS would do something similar at some point but these days it doesn't seem to do much other than crash and burn. Anyway this does quite conveniently create a "virtual" type scenario of sorts similar to what we are after, only specific libraries are available locally. Perhaps sticking with this convention would increase accessibility and flatten the learning curve. This same vendor folder might be the most logical location, for a PHP developer, to house a .phpenv-virtualenv or similar folder containing the virtualenv localization files. Thoughts?

The php include path, which is configurable in php.ini will assist in specifying the "virtual" location for installed libraries.

[iolloyd]

Let's decide on an MVP to get this rolling. I propose that an MVP would be to be able to run a command (virtualphp) that does the following:

1. Sets $PATH so that which php points to something like ~/.vphp/version/5.5/bin/php
   2.Sets the configuration to ~/.vphp/etc/php.ini
2. Sets the relevant extension folders as subdomains of ~/.vphp.

[jwoodcock]

Have you all looked at the source for virtphp? It does all the things I believe you are looking for in virtualphp

[jwoodcock]

For a detail look at virtPHP and how it works, here's a demo video:
https://www.youtube.com/watch?v=vQZ_SpTMo24