Search for Ansible modules

[abyth]

An Alfred workflow to search the Ansible module documentation.

Requirements

As macOS still ships Python 2 which is no longer supported since January 1st, 2020 - Python 3 is required to be installed. Due to the usage of f-strings at least Python 3.6 is required. The workflow uses the Python 3 interpreter returned by

/usr/bin/env python3

 so the installation method won't matter. However, i do recommend the usage of homebrew. The CI tests on github cover python version up from 3.6.

 

Required modules can be installed using pip:

/usr/bin/env python3 -m pip install -r requirements.txt

 

Installation

You can either download the workflow from Packal or the release page of the github repository

• http://www.packal.org/workflow/ansible-documentation-search
• https://github.com/abyth/alfred-ansible-workflow/releases/tag/v1.0

Usage

The workflow is triggered using the keyword ansible and will use the following input as search parameters.

 

 

Pressing enter on any of the results will open the corresponding documentation page in the default browser.

 

Edited February 28, 2021 by abyth
Added packal url

[deanishe]

5 hours ago, abyth said:

The workflow uses the Python 3 interpreter returned by

 

You’ve actually hardcoded /usr/local/bin/python3:

 

query=$1

/usr/local/bin/python3 ansible.py ${query}

 

FWIW, there’s little point in using /usr/bin/env in a workflow. Mac apps don’t use your shell environment, so /usr/bin/env python3 is basically always going to be /usr/bin/python3.

[Alan He]

Dash is better.

 

[abyth]

21 hours ago, deanishe said:

 

You’ve actually hardcoded /usr/local/bin/python3:

 

query=$1

/usr/local/bin/python3 ansible.py ${query}

 

FWIW, there’s little point in using /usr/bin/env in a workflow. Mac apps don’t use your shell environment, so /usr/bin/env python3 is basically always going to be /usr/bin/python3.

My bad..  must have happened while testing different launch options. Is there a common best practice for that? 

[deanishe]

42 minutes ago, abyth said:

Is there a common best practice for that?

 

For workflows? If you’re going to release it, today I’d recommend hardcoding /usr/bin/python3 and calling it “Catalina and later only”.

 

Perhaps use

export PATH=/bin:/usr/bin:/usr/local/bin
python3 myscript.py "$1"

to allow it to fall back to a Homebrew Python 3 on older OSes.

 

I’m generally a fan of hardcoding the system version of Python, so you know what you’re going to get. You never know what other people have symlinked to /usr/local/bin/python3, and it'll likely be you they ask for help when your workflow doesn't run on some weird, stripped-down Anaconda Python they've installed.