src relative to current playbook?

[Nolan Darilek]

Thanks for all your tips and advice so far. Here's something else I
encountered that I'm not sure how to resolve.

I'm building my playbooks such that they can bootstrap a system mostly
from scratch for even high-level tasks. For instance, my playbook which
sets up a VCS repository expects that I'm running LightTPD, so it calls
out to a generic playbook to ensure that Lighty is installed. Similarly,
it expects that CGI is configured, so it calls another playbook to
configure Lighty for CGI and to upload a configuration that adds
index.cgi as an index file type.

Because these Lighty configs are generic to a number of playbooks, I
have them in an include directory. So, something like:

include/lighttpd.yml: Makes sure the lighttpd package is installed.
include/lighttpd_cgi.yml: Configures Lighty for CGI.
include/lighttpd_cgi/cgi-tweaks.conf: Configuration for local,
CGI-specific tweaks. Copied to server via lighttpd_cgi.yml.
fossil/root_project.yml: Sets up a Fossil project on the root of a
specified domain, includes include/lighttpd.yml and
include/lighttpd_cgi.yml.

The problem is that, when lighttpd_cgi.yml tries to copy
lighttpd_cgi/cgi-tweaks.conf, the file isn't found. It uses a path
relative to itself.

I suppose I can refer to this file as if all playbooks will be in some
subdirectory, so ../include/lighttpd_cgi/cgi-tweaks.conf. But include
directives seem to work relative to the file that includes them. I
wonder if it might make sense for paths relative to src to originate at
the directory of the file that calls them? Then I can reference
lighttpd_cgi.yml from anywhere and it will always find
lighttpd_cgi/cgi-tweaks.conf, without having to unwind the current
directory first.

Is this currently doable?

Thanks.

[Michael DeHaan]

On Thu, Oct 25, 2012 at 7:10 PM, Nolan Darilek <no...@thewordnerd.info> wrote:
> Thanks for all your tips and advice so far. Here's something else I
> encountered that I'm not sure how to resolve.
>
> I'm building my playbooks such that they can bootstrap a system mostly from
> scratch for even high-level tasks. For instance, my playbook which sets up a
> VCS repository expects that I'm running LightTPD, so it calls out to a
> generic playbook to ensure that Lighty is installed. Similarly, it expects
> that CGI is configured, so it calls another playbook to configure Lighty for
> CGI and to upload a configuration that adds index.cgi as an index file type.
>
> Because these Lighty configs are generic to a number of playbooks, I have
> them in an include directory. So, something like:
>
> include/lighttpd.yml: Makes sure the lighttpd package is installed.
> include/lighttpd_cgi.yml: Configures Lighty for CGI.
> include/lighttpd_cgi/cgi-tweaks.conf: Configuration for local, CGI-specific
> tweaks. Copied to server via lighttpd_cgi.yml.
> fossil/root_project.yml: Sets up a Fossil project on the root of a specified
> domain, includes include/lighttpd.yml and include/lighttpd_cgi.yml.
>
> The problem is that, when lighttpd_cgi.yml tries to copy
> lighttpd_cgi/cgi-tweaks.conf, the file isn't found. It uses a path relative
> to itself.

Basically the underlying problem is that Ansible's "path_dwim" (do
what I mean) function only passes down one directory to look for
relative files in (as well as directories of included task files).

This is obviously not ideal, and the fix is to pass in all directories
of ALL playbooks, and be smart and try to find the file in any of
them.

For now, file paths relative to the top level playbook *do* work, but
I completely agree this is suboptimal.

It's something we'll have resolved for 0.9.