Multi-part library/ modules?

[ja...@ioctl.org]

Any executable from a playbook's library/ is shipped out as a single file,
it seems.

This makes writing local custom modules in (say) Python a bit of a PITA:
2,000 lines of Python that conflates several cross-cutting concerns that'd
be better broken out into custom modules available to import from a main
utility would be much more preferable.

Is there any support for doing this at the moment? Anything on the
roadmap?

At the moment it seems that at best I'm going to have to pre-ship my
actual tools and just write a module to shim around them. Is that current
practice?

Cheers,
jan

--
ja...@ioctl.org http://ioctl.org/jan/ Short, dark, ugly: pick any three
OORDBMSs make me feel old; I remember when this was all fields.

[Brian Coca]

I would ask what is it that you need to do that requires soo much code?


--
Brian Coca

[ja...@ioctl.org]

On Sun, 8 Feb 2015, Brian Coca wrote:

> I would ask what is it that you need to do that requires soo much code?

Stuff that'd be expressible (with a little work) as ansible tasks; the
installation of some software - but, it ain't via yum or apt.


(- Why not just use ansible task lists?)

The technology for deployment and installation will change over time; I
want to abstract that so consumers writing ansible don't have to _touch_
their playbooks at all if/when our packaging technology choice changes.

(- why not use includes?)

Considered it; it might still be on the cards, but the include syntax to
refer to a shared 'library' is a bit clunky and error-prone compared to a
straightforward task name. (That's why I think some kind of
macro-definition facility to let ansible give a name to a common series of
operations isn't a bad idea - it lets me raise the level of abstraction
just enough that my main playbooks are rather more readable.)

(- why so much code?)

There are a handful of orthogonal concerns: fetching the artifacts to be
deployed, FS management, a smidgen of configuration, host-side locking
around all these operations. I _could_ slap these all into one honking
library/ module but it'd be hard to maintain and test compared to having a
handful of stand-alone Python modules that I can use the traditional
Python approaches on.

(- why not package the code out as a separate installable and ship that
out-of-band, invoking that with a stub library method?)

That's the route I'm pursuing now. Slight road-bump 'cause AnsibleModule
doesn't live in something that I can use as a regular library*, but that's
relatively trivial; it's the avenue I'm going down.

* I'd hoped to save myself some time with argument parsing and validation,
which AnsibleModule does a reasonable job of.


Cheers for the attention on this - I appreciate your time.

[Brian Coca]

We try to avoid having modules too too much and keep them as small
reusable components, this goes very much against that.

Most people use roles to achieve this, or at least includes, but if
you feel this is your only approach ..., you know the problem you are
solving better than I.


--
Brian Coca