Is there any decent way to distribute complex PHP CLI scripts?

[DWilliams]

I wrote a fairly complex non-web PHP server application that runs via the PHP CLI instead of on the web through a web server as most PHP scripts are designed. PHP likely wasn't the ideal language to develop a server app on, but I did it for two reasons: 1. PHP is the language I work with most and 2. Why not? The capability is there, albiet mostly turned off.

 

Now the biggest problem I have here is portability. I mostly wrote this for myself but I'd like other people to be able to run it if they want. My program requires PHP compiled with pcntl and socket server support. First problem is that Windows apparently does not support PHP with pcntl extensions. Right off the bat that restricts my program to Unix-like platforms (which isn't really a problem for me, I'm fine with not supporting Windows). Since my script requires PHP compiled with extra features, I can't just give out my script and say "here run this". Another issue is that most users (myself included), would not run a version of PHP in any sort of serious environment that allows powerful (and hence dangerous) PHP extensions.

 

Rambling aside, is it safe to say that distributing a script that requires unusual PHP extensions is a gigantic pain pita and near impossible to distribute easily?

[trq]

Rambling aside, is it safe to say that distributing a script that requires unusual PHP extensions is a gigantic pain pita and near impossible to distribute easily?

 

Because most (if not all) Linux distributions have there own package management systems distribution should be rather simple. Release a pure src version allowing a manual install and simply list any dependencies within a README file. Then, either you or someone else could maintain distro specific packages. eg; deb, rpm or ebuild scripts.

[DWilliams]

Rambling aside, is it safe to say that distributing a script that requires unusual PHP extensions is a gigantic pain pita and near impossible to distribute easily?

 

Because most (if not all) Linux distributions have there own package management systems distribution should be rather simple. Release a pure src version allowing a manual install and simply list any dependencies within a README file. Then, either you or someone else could maintain distro specific packages. eg; deb, rpm or ebuild scripts.

 

I considered this but the problem as I see it is that enabling socket servers and pcntl appears to require PHP to be compiled with those options. I don't think there are any packages I can flag as dependencies and have them installed automatically. I run Arch on my home machine and didn't see any package in the official repositories (or AUR for that matter), and now I'm here at work and on one of our Ubuntu machines I see a php-net-socket package which might allow listening sockets but still I see nothing about pcntl.

[trq]

I don't think there are any packages I can flag as dependencies and have them installed automatically.

 

That is pretty much what package managers do. If however (as you have found) the packages you depend on are not available through whatever package manager you (or the end user) are using you won't have much choice but to have them manually install the application.

 

Obviously, you should try and avoid uncommon dependencies when writing an application for distribution.

 

What you could also do however (and this will mean allot more work) is actually provide (and maintain) the dependencies yourself as packages as well.