This guide demonstrates how to launch an Intel ipex-llm Docker container, start a vLLM API server configured for the Qwen3-8B model with tool-calling capabilities, query the server using curl, and interpret a sample response. Then, we’ll develop a simple agent loop with tool calling using the amazing litellm library.

This setup enables running large language models (LLMs) on Intel XPUs with features like automatic tool choice and reasoning parsing. All commands assume a Linux environment with Docker installed and access to Intel hardware (e.g., via /dev/dri).

When your orchestration logic becomes complicated, you can end up with lots of hardly readable YAML code, and it’s not very nice to maintain, ie. when mutating variables with combinations of template filters, set_fact and the like. The solution is to switch the logic code from YAML to Python, which is an actual programing language.

As you might know: Ansible Modules which are uploaded to the target host, executed there, and have their result returned to Ansible.

In this article, we’re going to present some of my favorite Python object oriented and meta programming features to refactor code, as well as other basics required to kill it with Python, a bit of packaging, some testing patterns. I hope this will help my friends to understand my code and to adopt a global vision for their internal libraries set.

Object Oriented Basics

Object Oriented allows to refactor and tidy up code by binding a state (attributes, variables) to a bunch of functions (called methods).

ansible ad hoc command line

The ansible command line allows you to use a single Ansible module without writing a playbook. Useful for one-shot commands, it is also a great way to verify that Ansible can work on a given server and to test different CLI arguments that will work both with the ansible and the ansible-playbook commands.

Use the ansible command line with the ping module to verify that Ansible can work on a target server:

Are you ready to revolutionize your command-line experience? Say hello to prompt2, the cutting-edge software that brings the power of AI directly to your terminal. Whether you’re a developer, a sysadmin, or just a tech enthusiast, prompt2 is here to supercharge your productivity and creativity.

Why prompt2?

• Prompt Engineering Playground 🎮: Iterate and refine your prompts faster than you can say “ChatGPT”. prompt2 gives you the tools to experiment and perfect your AI interactions.
• Terminal Native 🖥️: Designed for the keyboard warriors who live in their terminals. Feel right at home with a CLI that speaks your language.
• Jinja2 Turbocharged ✨: Harness the power of Jinja2 templating with magic variables like {{reads}}, {{writes}}, and custom filters to create dynamic, powerful prompts.
• Cache Commander 💸: Save on API costs with automatic response caching, reducing expenses by over 40%.
• Plugin Ecosystem 🔌: Extend prompt2 with ease using Python’s simple plugin system. Add custom backends, parsers, and filters to tailor the tool to your needs.

Getting Started with prompt2

Ready to dive in? Here’s how to get started:

chttpx also registers as a pytest plugin, because as you know, I’m pretty lazy when it comes to repetitive test writting which is why I developed django-dbdiff and django-responsediff and also cli2.test.autotest. Let’s have the same thing with chttpx!

Let’s write a test that calls the object create and delete command, say, in the tests/test_client_test.py file:

@pytest.fixture
def test_name(ts, chttpx_vars):
    # ts is a fixture provided by this plugin which contains the timestamp
    # chttpx_vars is variables that will be attached to the test fixture
    # doing this ensures you get either the fixture saved test_name either
    # a new one, unique thanks to the timestamp
    return chttpx_vars.setdefault('test_name', f'test{ts}')


@pytest.mark.chttpx_mock
def test_object_story(test_name):
    obj = APIClient.cli['object']['create'](f'name={test_name}')
    assert obj.name == test_name

    with pytest.raises(chttpx.RefusedResponseError):
        # test_name already exists!
        APIClient.cli['object']['create'](f'name={test_name}')

    APIClient.cli['object']['delete'](f'{obj.id}')

The first time you run this test, our example APIClient will connect to localhost:8000 as it’s configured by default, and actual queries will be exeuted:

cli2 v4 is out!

Well, cli2 started as a minuscule thing, basically it was supposed to be just a CLI

But, since 2018, it became my personnal automation framework to crush any DevOps gig on my way by automating absolutely everything in record efforts.

It ended up including all the following batteries:

• beautiful CLI alternative to click, but much less verbose, allowing more creative design patterns without any boilerplate thanks to introspection
• which comes with a Sphinx extension to extensively document your CLIs
• magic 12-factor configuration library
• extremely beautiful structlog configuration for colorful and readable logging
• httpx client wrapper that handles all kind of retries, data masking…
• magic ORM for HTTP resources based on that client
• Ansible Action plugin library with all the beautiful logging and a rich testing library so that you can go straight to the point in pytest
• a good old fcntl based locking
• a command line to run any python function over a beautiful CLI

And … that’s probably why v3.3.46 became a disgusting mess! Fear not, v4 is out and super easy!

This tutorial aims to teach Git basics to work in a team.

In this tutorial, you are going to have 3 roles:

• the git server,
• Alice, a developer
• Bob, another developer.

Git central

First, create what will serve as central git server for this tutorial:

git init --bare git-central

This will output something about master branch being non-inclusive, you can discard this message.

But it will specifically output:

Initialized empty Git repository in ~/git-central/

Alice and Bob will pull and push sources to ~/git-central/ just like if it was a gitlab server, because it’s a “bare” repository.

Humans have used containers for at least 100,000 years, and possibly for millions of years. The first containers were probably invented for storing food, allowing early humans to preserve more of their food for a longer time, to carry it more easily, and to protect it from other animals. The development of food storage containers was “of immense importance to the evolving human populations”, and “was a totally innovative behavior” not seen in other primates.

Read More

pytest is an awsome Python Test framework which starts over from a clean slate instead of following the xUnit pattern.

Instead of:

class YourTestSuite(unittest.TestCase):
    def setUp(self):
        self.some_stuff = YourThing()

    def test_delete(self):
        self.some_stuff.delete()
        self.assertFalse(self.some_stuff.exists())

We do:

@pytest.fixture
def some_stuff():
    return YourThing()


def test_delete(some_stuff):
    some_stuff.delete()
    assert not some_stuff.exists()

A couple of advantages are worth noting:

• the fixture is not created in every test
• we also win one indentation level which is pretty cool!

However, what about complex code where we test the glue between over a dozen of fixtures?