One way for many things to return changed status appropriately would be use of "creates=" and "removes=" for things that create files.
However, I do understand if you are writing a module that needs to make 5000 PHP API calls and no CLI already exists for Ansible to cleanly shell out to. If you limit this to things that only interact with PHP APIs, I think what you are doing is fine, so what this really is is a small set of utility functions to return things in JSON, etc, that made it a little easier for you to write modules in PHP. That's fine, in most cases though, a python module that calls a CLI would be a better route. I don't know all of your cases though, since I'm not a PHP guy and don't know those mentioned tools. Since this is just making sure you return some valid JSON, and this isn't fundamentally different from how Ruby modules work today. Example repo to show how cross-language modules work: https://github.com/ansible/ansible-for-rubyists/ https://github.com/ansible/ansible-for-rubyists/blob/master/library/my_ruby_calculator What I would caution is that if you are working with a team of people that do know Python, and also want to contribute things back to Ansible, this is crossing a boundary where we can't take those things back in core. This is the main problem I would see, and you can possibly make things harder to work on in your team if people are used to Python -but Ansible isn't a purist in this category by any means. Just that all core modules are Python, and more utility functions are always going to be available there, because that's where we spend time. An example of using a CLI vs an API here is our Ruby gem library is still useful, but it's written in Python, because it uses the "gem" CLI tool and doesn't need to be written in Ruby. The other advantage of this is that if the API were to change, the CLI usually stays the same, so it's more loosely coupled. I will at least agree with Tim in that PHP is a terrible language, but in the end it doesn't matter if that's what you have to talk to and a job needs to be done :) On Wed, Jul 9, 2014 at 6:23 PM, Andrew Udvare <[email protected]> wrote: > On Wednesday, 9 July 2014 14:39:48 UTC-7, Timothy Appnel wrote: >> >> I've absolutely read over this thread and the project page. You've ported >> the ansible module helpers to PHP so you can write your modules in PHP >> rather than learn some Python and use what's already there. > > > I have written several modules in Python. I am very familiar with Python. > That is my go-to language for just about anything. All of the problems I am > solving with this library I have already done workarounds for either in the > tasks (combined with other tasks usually) or in Python-based modules, but > they are very ugly and not close to as good at reporting information back. > > If some code (an Ansible module) needs to check something that is not > readily available as a file, and non-trivial to get to in Python, I think > the best way to get that information is by hooking in directly to that API > compared to coming from the outside with a Python-based module, executing a > script via command/shell (like Drush or WP-CLI as explained in my > documentation, which sometimes give no indicators to state change; and also > can be very slow with no chance at optimisation), or worse yet attempting > at re-implementing any of that code in Python (which is pointless because > all of these sites call upon 3rd party code that has to be called properly > in order for the database to stay consistent). In terms of Drupal and > WordPress, these are not well-designed frameworks in that sense. No one > will disagree with that. But they still exist and people still use them. I > simply want to provide reliable deployment with as much accurate > information as possible, and to minimise the copy-paste of code in any > PHP-based module. > > In addition to providing an API similar to Ansible's own but in PHP, I am > also trying to alleviate some non-obvious PHP pitfalls like error/exception > handling (all errors call a fail_json()-like function and provide (as > useful as possible) a backtrace) and JSON encoding (which properly calls > json_last_error() in PHP every time). Having a 'simple' (one file) PHP > module would be nice, but then you would have copy-paste in every module > you create in PHP. And that would be the same case in Python if Ansible did > not provide a library. > > This would not be any different to me if a large code base was written in > any other language, and has no Python API (or REST API) to check/change > things (which is the case for a lot of things). I would still considering > putting together a module in that language (or whatever works best) so I > can get the best access to the information and give as best as possible > feedback on changes made during deployment. > > What I do not want is that just because it is some non-Python thing and/or > cannot be reliably be managed via Python that the command/shell module says > '"changed": true' every single time. That is generally useless especially > if the command is actually idempotent in one way or another but Ansible > (even with changed_when and inspecting stdout or rc) cannot detect that. > > Finally, nobody is forced to use this for PHP or anything else. It is > merely a suggestion. But it does hook into existing projects relatively > easily, with only a few caveats. And indeed there are people out there who > will not approach writing an Ansible module because they do not know > Python. I do not see anything wrong with providing a tool. > > -- > 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/565dbfa8-d266-4e5f-81a8-989d1227fcf6%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/565dbfa8-d266-4e5f-81a8-989d1227fcf6%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/CA%2BnsWgwH9runn0mGHFkK7NSDjGJQTm57H80FFbc2x0%3De29YuvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
