VirtPHP: Filling a Non-Existing Gap

Daan Debie / March 15, 2014

7 min read

About a week ago, a tweet caught my eye about a project called VirtPHP. Now, I don’t follow many people from the PHP community anymore, because I’ve really grown to dislike PHP over the past few years, and I’ve mostly gone off to greener pastures. But I still follow a couple of folks, most notably from the Symfony & Doctrine projects, because I’m a masochist, and I’m morbidly interested in how this whole PHP mess is going to evolve…

Anyways, this is the relevant tweet:

Naturally, I took a look at the project, and soon a short exchange of words with the project’s initiators followed:

At the time, I didn’t feel like spamming my elaboration in 140-character snippits on Twitter, but I realized that the faults I see in virtPHP are part of a more pervasive problem in see in PHP-land: people putting lots of time (1 year in this case, for only an alpha version!) into problems that don’t need solving.

In this post I want to elaborate on why virtPHP solves a problem that doesn’t actually exist.

What Problems Does VirtPHP Try to Solve?

As far as I could deduce from the tweets, the website and their GitHub repo, virtPHP is a tool that allows you to create separate PHP environments. That allows you to do the following:

  • Use differing sets of PECL extensions
  • Use different PEAR packages, including different versions of the same package
  • Use different versions of PHP

(Also, according to the website "Note: virtPHP is currently only targeted to command line php (php-cli) for *nix based systems." Does this mean I can’t use virtPHP for having different PHP installs for developing web applications?!)

Granted, I’ve been out of the PHP loop for a while now, but I still have a pretty decent grasp of what’s going on there. So I’ve come to the conclusion that in the current state of affairs with regards to PHP development, all those problems are solved already or don’t need to be solved.

Package Management

Despite my dislike for PHP, I don’t think it’s all Fire & Brimstone. In fact, one of the things the PHP community did get right is Package Management. With the arrival of Composer, package management - using third party libraries and frameworks - has become rediculously easy. PEAR is quickly becoming a thing of the past, if it hasn’t already.

On the its website, virtPHP gets likened to virtualenv. Even the name resembles its Python counterpart. For those who don’t know: virtualenv allows Python programmers to have separate environments to develop in, for different projects, much like virtPHP advertises. Now, as I’ve mentioned in my tweets, virtualenv is a necessary contract within the Python world because of how package management is set up. When you install a package for Python, using easy_install or pip, packages get installed system-wide. They will end up in a place related to your Python interpreter. The same goes for using installing Rubygems for Ruby, using gem install. When working on different projects, that can quickly become a mess of conflicting dependencies and versions.

Composer however, solves this neatly by installing packages in a vendor directory, relative to your project root. In a way, it’s more a dependency manager than a package manager, it even says so on the website. Bundler for Ruby does the same. This removes the need for separate environments to avoid conflicts between packages and projects.

Seeing that Composer negates the need for using PEAR (which virtPHP mentions) for installing packages, there’s no problem that virtPHP needs to solve in relation to package management.

Pecl Extensions and Php Versions

The other usescases for virtPHP have to do with managing different sets of PECL extensions and different PHP versions. PECL is a system for distributing PHP extensions. Let me start by saying that the need for extensions to the PHP core is dangerous at best. If you need extra functionality, then there are PHP packages for that, that can be installed with Composer. Or we might be talking about PHP bindings for some C library, but in my opinion it should be trivial to include those as a package in your project as well. If some feature really merits writing a C extension for that, it’s probably better suited as a part of the core language.

Now, there are some scenarios in which © extensions are a necessary evil. For instance if you want to use ImageMagick, you’ll need the PHP bindings, which come in the form of an extension. Installing extensions, and especially switching between extensions, should not be a thing you do often, though. I really doubt if you’ll ever bump into conflicts because of extensions you installed. Most extensions shouldn’t bother you if they’re installed, but you don’t use them in a project.

Switching between PHP versions could be the only legitimate usecase for virtPHP, but only if you’re developing a library that is going to be used by lots of people with lots of different PHP versions you need to test/develop against. In all other cases - building webapps mostly - I’m assuming you have complete control over the production environment, so you can choose which PHP version your projects run on. It’s easy then to develop all your projects against that version, and there’s no need to switch to different versions.

It’s interesting to note, by the way, that according to it’s website, virtPHP doesn’t actually let you install different PHP versions side by side. You need other tools for that.

Should you still want to use different versions of PHP with different extensions installed, you’re still not going to use virtPHP, because there are better solutions…

Separate Development Environments Done the Right Way

If you really want to have different development environments for different projects, and as an added bonus have parity between your production systems and development environments, you should setup Virtual Machines to run your code on, using Vagrant and some form of provisioning.

In fact, you don’t even have to understand how provisioning tools work. There are multiple tools to help you setup disposable development environments with your exact specifications:

I highly suggest you give them a spin to make your life and that of your fellow developers much easier!

Conclusion

The world does not need virtPHP. Package mangement is a solved problem for PHP these days, and using different PHP versions and language extensions is mostly a non-issue. But the real problem with virtPHP is that you should approach the problem of having different development environments for different projects, from a whole different angle. Devops is hot these days, and it has given us many tools to help us out in that department.

It’s shocking to me that people would spend a year to develop a tool without actually finding out if the problems they’re trying to solve, has been solved already. Maybe that’s part of the PHP-problem, the community should spend their time more wisely.

All posts by topicArchive

Copyright 2024 - Daan Debie