django-autocomplete-light a deux lignes de versions actuelles avec des rôles différents : v4 existe pour fournir le chemin de mise à niveau documenté depuis v3 et à travers les versions Django prises en charge, tandis que v5 est l’endroit où nous pouvons prendre les ruptures de compatibilité arrière plus importantes qui débloquent la prochaine API.

Cet article clarifie à quoi sert chaque ligne, laquelle vous devriez installer, et où trouver la documentation de mise à niveau.

Un réseau d’entreprise classique ne permet pas aux admins de se connecter directement aux machines qu’ils administrent, et obligent à la connexion à une machine intermédiaire: le bastion.

On ne va pas pouvoir être exhaustif sur ce guide tant il existent de techniques pour contourner ce type de limitation, nous nous contenterons ici de présenter les diverses options de SSH, ainsi qu’un proxy SOCKS séparé à savoir Dante (sockd), et comment les combiner dans divers scénarios d’entreprise.

Ce guide montre comment lancer un conteneur Docker Intel ipex-llm, démarrer un serveur API vLLM configuré pour le modèle Qwen3-8B avec des capacités de tool calling, interroger le serveur avec curl, et interpréter une réponse d’exemple. Ensuite, nous développerons une boucle d’agent simple avec tool calling en utilisant l’excellente bibliothèque litellm.

Cette configuration permet d’exécuter de grands modèles de langage (LLMs) sur des XPUs Intel avec des fonctionnalités comme le choix automatique d’outils et le parsing du raisonnement. Toutes les commandes supposent un environnement Linux avec Docker installé et un accès au matériel Intel, par exemple via /dev/dri.

Quand votre logique d’orchestration devient compliquée, vous pouvez vous retrouver avec beaucoup de code YAML difficilement lisible, et ce n’est pas très agréable à maintenir, par exemple quand vous mutez des variables avec des combinaisons de filtres de templates, set_fact et autres. La solution est de passer le code logique de YAML à Python, qui est un vrai langage de programmation.

Comme vous le savez peut-être : les modules Ansible sont téléversés sur l’hôte cible, exécutés là-bas, puis leur résultat est renvoyé à Ansible.

Ligne de commande ad hoc ansible

La ligne de commande ansible permet d’utiliser un seul module Ansible sans écrire de playbook. Utile pour des commandes ponctuelles, c’est aussi une très bonne façon de vérifier qu’Ansible peut fonctionner sur un serveur donné et de tester différents arguments CLI qui fonctionneront à la fois avec les commandes ansible et ansible-playbook.

Utilisez la ligne de commande ansible avec le module ping pour vérifier qu’Ansible peut fonctionner sur un serveur cible :

chttpx s’enregistre aussi comme plugin pytest, parce que comme vous le savez, je suis assez paresseux quand il s’agit d’écrire des tests répétitifs. C’est pour ça que j’ai développé django-dbdiff, django-responsediff et aussi cli2.test.autotest. Faisons la même chose avec chttpx !

Écrivons un test qui appelle les commandes de création et de suppression d’objet, par exemple dans le fichier tests/test_client_test.py :

@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}')

La première fois que vous lancez ce test, notre APIClient d’exemple se connectera à localhost:8000, comme il est configuré par défaut, et de vraies requêtes seront exécutées :

cli2 v4 est sorti !

Bon, cli2 a commencé comme une toute petite chose : à la base, c’était censé être juste une CLI.

Mais depuis 2018, c’est devenu mon framework d’automatisation personnel pour écraser n’importe quelle mission DevOps sur mon chemin, en automatisant absolument tout avec un effort record.

Il a fini par inclure toutes les piles suivantes :

• une belle alternative CLI à click, mais beaucoup moins verbeuse, qui permet des patrons de conception plus créatifs sans boilerplate grâce à l’introspection
• une extension Sphinx pour documenter largement vos CLIs
• une bibliothèque magique de configuration 12-factor
• une configuration structlog extrêmement belle pour des logs colorés et lisibles
• un wrapper client httpx qui gère toutes sortes de retries, le masquage de données…
• un ORM magique pour des ressources HTTP basé sur ce client
• une bibliothèque de plugins d’action Ansible avec tous les beaux logs et une riche bibliothèque de test pour aller droit au but dans pytest
• un bon vieux verrouillage basé sur fcntl
• une ligne de commande pour exécuter n’importe quelle fonction Python via une belle CLI

Et… c’est probablement pour ça que v3.3.46 est devenue un bazar dégoûtant ! Pas de panique, v4 est sortie et elle est super simple !

Les plugins d’action Ansible sont la meilleure façon de refactorer des rôles Ansible complexes et d’y encapsuler de la logique DevOps avancée. Mais la documentation officielle est un peu légère, et conclut par :

Pour des exemples pratiques de plugins d’action, consultez le code source des plugins d’action inclus avec Ansible Core

J’ai passé 3 ans à faire de la rétro-ingénierie des plugins d’action Ansible et à écrire les miens, en faisant des choses qui ressemblent vraiment à de la magie, y compris de la sortie animée, qui s’avère fonctionner même dans GitLab-CI, qui prend en charge le caractère backspace.

pytest est un excellent framework de test Python qui repart d’une page blanche au lieu de suivre le patron xUnit.

Au lieu de :

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())

On fait :

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


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

Quelques avantages méritent d’être notés :

• la fixture n’est pas créée dans chaque test
• on gagne aussi un niveau d’indentation, ce qui est plutôt cool !

Cependant, que faire avec du code complexe où l’on teste la colle entre plus d’une douzaine de fixtures ?

Bonjour à tous!

Le 3 Mai, c’est le 11ème anniversaire du premier commit sur le premier logiciel libre de YourLabs qui nous a fait connaitre !

Tous les anciens, contributeurs, clients, et fournisseurs, de YourLabs sont donc invités au hackerspace pour une soirée dans l’esprit des meetups Hack’n’Dev (interrompus par le COVID et qui vont reprendre cette année):

• barcamp arrosé
• toast
• barbecue
• live music

Pour ceux qui arrivent en train, un chauffeur viendra vous récupèrer à la gare d’Angoulême.