* Package name    : elpa-ansible
  Version         : 0.2.0
  Upstream Author : Ken’ichiro Oyama <k1lowxb@gmail.com>
* URL             : https://github.com/k1LoW/emacs-ansible
* License         : not licensed?
  Programming Lang: elisp
  Description     : ansible syntax highlighting, completion, and yasnippet templates for Emacs

Ansible (already in Debian) is a configuration management tool.
Ansible file format is a combination of YAML (structured data) and jinja2 (templates).

elpa-yaml (already in Debian) is mostly sufficient;
adding ansible.el gives some domain-specific syntax highlighting.

e.g. yaml-mode colors these lines the same; ansible.el colors the
first line specially (because it has special meaning to Ansible).

    name: foo
    bar: baz

ansible.el also has some stuff to auto-complete ansible keywords
(e.g. "na<TAB>" --> "name"), and some basic yasnippet-based templates.
I (Trent Buck) personally do not care about those features.

Hi Trent,

Thank you for investigating and filing this RFS.  Reply follows inline.

"Trent W. Buck" <trentbuck@gmail.com> writes:

I've filed an upstream issue about including the full license text.

Thank you for taking the time investigate and to write a nice description!

Continuing from Bug #941058

Good point, that doc issue ought to be fixed upstream.  Also, I suspect
that the conversion to a derived major mode should be done before this
software is suitable for a Debian stable release.  Finally, it would be
nice if the snippets were merged into Andrea Crotti's official upstream
snippets collection once ansible mode has been modified to be a derived
major mode.  I'm not sure if the .yas-parent functionality will work
properly without this change, and it would be nice to provide the
yaml-mode snippets + ansible snippets (via .yas-parent) simultaneously,
for users who enjoy this type of functionality.

Were you able to tell if the autocompletion and yasnippets are so
limited as to be not useful to people who use this functionality?  The
snippets appear to be surprisingly comprehensive to me.

Excellent work, are you interested in joining the Debian Emacsen team?
It's clear you have the skills. :-)  I'd be happy to answer questions
and provide guidance if necessary.
parser, and should go in the long description.  Whoever fulfills this
RFP should verify that this functionality can catch jinja2 syntax errors.

I'll add it to my low-priority "to package eventually if someone else
doesn't step forward" queue.


Take care,
Nicholas

Nicholas,

Eliding the parts I agree with...

Nicholas D Steeves wrote:

I agree making it a local minor mode, instead of a derived major mode
(derived from yaml-mode) is a weird decision.

I *guess* this is because (AIUI) ansible has three file formats:

  1. yaml + jinja2
     (used for playbook.yaml and inventory.yaml)

  2. ini + weird magic
     (used for inventory.ini, instead of newer inventory.yaml)

  3. plain jinja2 templates
     (e.g. httpd.conf.j2, which becomes /etc/httpd.conf)

...and the ansible-mode author wanted to add the ansible
domain-specific magic to all three.

Personally I only really care about #1, so define-derived-mode from
yaml-mode makes sense to me.

Sorry, I did not investigate this closely.

If you install ansible on any old system, you can run

    ansible-doc --list   # pick one, e.g. "copy"
    ansible-doc copy

and scroll down to look at the examples.
You can see the same information here (slightly different version):

https://docs.ansible.com/ansible/latest/modules/copy_module.html#copy-module

The snippets look to me as if they are derived from these examples.

For me, alarm bells immediately went off because the emacs-ansible
snippets can get out of sync with what the actual ansible codebase
expects.

Most of the snippets seemed to only be 1 or 2 attributes anyway, something like

    - name: $1
      copy: dest=$2 $*

I wouldn't want to be in charge of constantly keeping those in sync with ansible.

...having just written that, I recall that some ansible modules are
flagged with "Red Hat promises not to break backwards compatibility",
so I guess those would be OK to have snippets for.

Ehhhh, maybe.  :-)
You can find me (as "twb") on #emacs on irc.freenode.net every day.
We can chat about it there.
It looks to me like it's just a single font lock for {{}}:

    (defvar ansible-playbook-font-lock
      `(("\\({{\\)\\([^}]+\\)\\(}}\\)"
      . #)

I would much rather have a "real" jinja2-mode be mixed into yaml-mode,
similar to how mhtml-mode handles CSS-in-HTML today.
(I realize this is a hard and unfun problem in Emacs.)

Once major gotcha: in ansible files,
the "when" clause has an implicit {{}}, where other clauses don't.
That's definitely domain-specific (i.e. ansible-only) behaviour.

So e.g.

    name: eat {{animal}} for food
    eat: food={{animal}}
    when: animal
    vars:
    - animal: trout

    name: >
      check if {{animal}} is neither a dog not a cat
      (answer is {{'dog' != animal and 'cat' != animal}}')
    eat: food={{animal}}
    vars: animal=trout
    when:
     - animal
     - "'dog' != animal"       # double-quotes are a workaround to avoid
     - "'cat' != animal"       # confusing the yaml parser - the jinja2 parser
                               # never sees them.