PECL package: .so filename and package name can differ

[netsensei]

I'm trying to install zmq-beta extension (https://pecl.php.net/package/zmq) as a PECL package via phansible. I've noticed that the phansible assumes that the .so filename of the extension, and the name of of the PECL package are one and the same. The value of the item variable in php/templates/extension.tpl is derived from php.pecl_packages in vars/all.yml.

However, this assumption isn't always true. As is in the case of the ZMQ extension.

In my vars/all.yml file:

php:
    install: '1'
    ppa: php5-5.6
    packages: [php5-cli, php5-intl, php5-mcrypt, php5-mysql, php5-gd]
    pecl_packages: [zmq-beta]

This results in a /etc/php5/mods-available/zmq-beta.ini file with this contents:

; Configuration for php PECL zmq-beta extension
extension=zmq-beta.so

However, the zmq-beta.so file does not exist:

$ php
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/zmq-beta.so' - /usr/lib/php5/20131226/zmq-beta.so: cannot open shared object file: No such file or directory in Unknown on line 0

$ ls /usr/lib/php5/20131226
gd.so    json.so    mysqli.so  opcache.so    pdo.so       xdebug.so
intl.so  mcrypt.so  mysql.so   pdo_mysql.so  readline.so  zmq.so

Currently, I can get around this by introducing an extra task to my playbook which renames the zmq.so file to zmq-beta.so. But wondering if we could provide an optional override in all.yml instead.

[naxhh]

You are right. Kind of weird that the package is named zmq and you need to refer to it as zmq-beta...
We should think on how to implement this. Should be easy to use and don't add too much complexity.

Also I think this should be part of phansible web and not role logic.

[debo]

In my opinion this should be threated as edge case, generally install beta packages shouldn't be the norm. What I'm afraid of is that we might end up needing to handle way too many exceptions

[naxhh]

We could start simple. Just fix this use case and see if any more arises.
When this becomes a problem we will think how to fix that.

Seems ok?

[netsensei]

+1 for approach of @naxhh: start simple, see where this potentially lands.

[debo]

I still think we shouldn't support this, reason being that in order to fix this the code will look something like

if ($lib == 'zmq-beta') {
    $configFile = 'zmq.ini;
    $extensionFile = 'zmq.so;
}

Which is something I'd rather avoid if possible for the obvious reasons I exposed earlier.
It's not a matter of simplicity, it's more decide whether we want to provide support for unstable packages or not to which I tend to vote for not.

[naxhh]

Let me think about this. It's true that beta packages are not in our scope.
But it's also true that we try to provide a full working php environment for the users.

[netsensei]

@naxhh I've been thinking about this too.

If you zoom back a bit, you'll notice that Phansible is already pretty opinionated: you can only choose from a list of preselected stable PHP versions, base boxes,... from the interface. The PECL dropdown doesn't even list the ZMQ package: it's not possible to select it.

But that's just the interface of Phansible. Then there's also the Ansible playbook that Phansible generates based of the selected configuration: this is where my use case comes in: I hacked the generated playbook directly. The structure of the playbook makes an assumption about the naming of the PECL package vs. the actual filename of the .so module.

=> I think it's fine to keep the visible interface (as seen on phansible.com) as is: Phanisble should always generate a usable, functional - albeit opinionated - baseline which can be hacked/tweaked on a per use case basis.
=> Still: you should be able to add your own PECL packages to the playbook without having to define explicit copy tasks because of an implicit assumption.

[debo]

I think we can probably do something clever. Yesterday I discovered on galaxy this role:

https://github.com/ansible-roles/ansible-role-php_pecl

It doesn't solve the problem but it gave me some ideas about how to workaround it in a flexible way. I'll try to do something about this issue today if I can cut some time from other projects.

[debo]

@netsensei just a quick apologetic message to let you know I didn't forget you, I've simply being a bit busy but now I'm back and I'm going to clear the backlog ;)