I have finished the project for now. Just so in case anyone is interested https://github.com/appdynamics/ansible-php . It requires PHP 5.3+ and Composer and all that. The README details everything.
Yes, it involves copying over the dependency but that actually is not as bad as I thought. If you already have a PHP project working with Composer you can just add this to it and use the composer module in Ansible to update dependencies. Unfortunately as said in the README you must provide a ansible_php option with every usage of a module written with this 'framework'. And also, the boilerplate mentioned in the README is a bit ugly but necessary. I think the best approach here is to get into your own code as soon as possible from your module, and then report changes. This may require changes in how your code functions (to get changes for example) but it's for the best IMO because it means better information during and after deployments. Andrew On Wednesday, 2 July 2014 14:42:43 UTC-7, Michael DeHaan wrote: > > Hi Andrew, > > We're unlikely to merge any PHP stubs into Ansible core because we cannot > easily maintain those things as a Python shop/community, nor do we want to > have any PHP modules in core. > > However, I believe in supporting mix-in stubs from various languages and > making common code insertion pluggable. > > Right now this is leveraged by: > > https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils > > And this covers Python based mixins. > > I'd say I'm *somewhat* interseted in making this a little more extensible, > but I'm also not positive I'd want to maintain that overhead. > > My gut feeling is you should find ways to write these things in Python, > perhaps the Python modules could be simple stubs that called a CLI based in > PHP if they needed to talk to PHP libraries. > > You can of course write modules in non-Python today, but there just isn't > a mechanism for sharing things without having pre-installed deps. > > But maybe sharing by deps isn't so bad either. > > I think it's not - if I am misunderstanding and this is about subtle > tweaks around enabling things like WANTS_JSON to work a little better with > PHP in the code that sends that over, I'm open to that, but I would almost > think that would look like the ruby example repo in github.com/ansible/ - > but correct me if I'm wrong. > > > > > On Tue, Jul 1, 2014 at 11:16 PM, Andrew Udvare <[email protected] > <javascript:>> wrote: > >> Has this idea been explored? >> >> I have started writing a set of PHP classes to be located here >> https://github.com/Appdynamics/ansible-php. The idea is to, as part of >> the task, if the module is determined to be written in PHP (check shebang), >> then copy this library over to the right place. The PHP process would be >> called with a custom INI file that would have include_path set properly. >> The module then only needs a short amount of code to start with just like a >> Python-based Ansible module. The primary use case would be with websites >> written in PHP that need easier interfacing than using Python. Typical site >> types include Drupal, WordPress, and sites written with the Syfmony 2 >> framework. While all of these have command line helpers (drush and wp-cli, >> Symfony 2 console), it is quite useless to have 'changed: true' every time >> you run a command (via command or shell modules) when nothing has really >> changed. >> >> Example module (the only boilerplate is the first 3 lines): >> >> #!/usr/bin/env php >> <?php >> require 'Ansible.php'; // class auto-loading file or just includes all of >> them >> >> $module = new AnsibleModule( >> array('dir' => array('type' => 'directory'), 'set_mode' => >> array('type' => 'bool'), 'mode' => array('choices' => array('production', >> 'staging', 'dev')) >> ); >> $include = $module->params['dir'] . DIRECTORY_SEPARATOR . 'somecode.inc'; >> $should_set_mode = $module->params['set_mode']; // === true or false, >> because of the type key in the argument specification >> $target_mode = $module->params['mode']; >> >> $changed = false; >> >> // Here, require the PHP code at the $dir argument, and set the >> application to the mode if $should_set_mode === true >> // If an error occurs, call $module->failJson(); optionally with an array >> of data >> >> $module->exitJson(array('changed' => $changed)); >> >> One area of concern is compatibility, so I am avoiding using new features >> such as namespaces. Perhaps the oldest version to go down to is PHP 5.2 >> (influenced mostly by CodeIgniter's standards). >> >> If this were to be seriously explored and merged into Ansible core, I >> would like to know where these files would go. The lib/ directory seems the >> most likely place. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/9760a8c8-eb80-4b5e-8e5c-70bfa7b0899c%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/9760a8c8-eb80-4b5e-8e5c-70bfa7b0899c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/fb456e48-c04a-441c-a1b9-af4d57823c1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
