This is a general meta-task which discusses building OS-specific install scripts, VM images, AMIs, OS packages, etc.
Overview
Although we no longer get nearly as much feedback about Phabricator being difficult to install as we once did, it isn't easy to install. Consequently, we receive requests to provide packaging, like:
- Make an install script for <some OS>
- Get Phabricator into the package manager for <some distro>
- Provide a VM/Vagrant/Container/AMI
- Support brew/composer
- Install man pages / init.d scripts / other hooks
We may pursue these things some day, but for now they're a very low priority, primarily because:
- Phabricator runs on a wide variety of operating systems (e.g., Debian, RedHat, FreeBSD, OSX, Solaris, some Windows support), and a wide variety of webservers (apache, nginx, lighttpd), and multiple PHP runtimes (Zend PHP, HHVM). We can not realistically build an install script which supports all of these options without monumental effort. Users have generally expressed much more interest in being able to run on obscure platforms and with specific configurations than in having a more straightforward install process.
- We're a small team, without expertise in packaging and distribution. None of us actually know how to do many of the things on this list.
- We're a small team with finite bandwith. Even if we were packaging experts, committing to building and maintaining this stuff would limit the bandwidth available for feature development. Although there's some level of chicken-and-egg / selection bias, we see far more demand from users for feature development than configuration simplification (and even for feature development over configuration simplification, e.g., "that feature would be awesome, it's completely fine if it's super hard to configure"). Particularly, this stuff is an ongoing investment since we need to keep it up to date as every supported OS and dependency evolves. We currently weigh the cost of building features which will requiring substantial ongoing maintenance heavily.
- Much of Phabricator's installation process involves interacting with dependencies. We can't just wipe out the Apache config or the MySQL config on a box, since they may be used for other things, and we can't always easily extend them either, since users can change their configuration and make it stop reading sites.enabled/ or whatever.
- Much of Phabricator's installation process is install-specific. For example, some install steps include setting up accounts, hostnames, mail, etc. There's no way anything prebuilt can do this for you, and we could make it easier only by taking over the entire system.
- Phabricator is a very fast-moving target, and we recommend installs update frequently. It would be difficult to keep some types of packages (like distro packages) anywhere near HEAD. Phabricator also has no regular versions/releases, and our current judgement is that a continuous release is a net benefit for both the upstream and users. For example, we are often able to fix issues that users report within hours, and having all users attached to HEAD means they can pull the fixes immediately after they're available. If we had to go through a package/distro system, it could take thousands of times longer to get fixes deployed.
- We don't have the infrastructure in place to automatically rebuild or automatically test these scripts/packages. This will improve in the future, but even once this infrastructure exists it will require a significant investment to make sure these things aren't immediately obsoleted, irrelevant or broken (see T1049).
- We're building a SAAS offering which will provide a zero-administration option (see T1315). For the set of users who would rather not deal with any administrative stuff, this is a preferable option to packaging, since it eliminates the problem rather than mitigating it.
- Phabricator's dependencies are mostly standard packages and almost all of the setup steps can be navigated by Googling for how to perform them. For example, if you want to write a startup script for phd for your OS, you can just Google for how to do this. Provided your OS offers a reasonable mechanism, writing this script should not be especially difficult.
The Way Forward
We may eventually pursue these things, but they're very difficult to prioritize for now because of the large surface area, high initial cost, and high maintenance costs. Focusing attention on packaging would distract from feature and application development, face significant limits in possible impact, and generally slow things down. At a minimum, we are unlikely to invest significantly in this stuff until after SAAS is built.
If you have expertise with an OS and would like to contribute something, we're happy to provide links to it, but generally don't have the bandwidth or expertise to maintain this stuff in the upstream.