MakeMake The Dwarf Planet is a feed agregator.

Atelier en ligne (en anglais) pour apprendre à proposer une conf <3 (PyLadiesCon)

by Mindiell from AFPy discuss

Join our free online CFP workshop to craft a great proposal!

Ca peut intéresser des gens je pense ;o)

1 message - 1 participant(e)

Lire le sujet en entier

Lire la suite…

AFPy

by AFPy - Mastodon from AFPy - Mastodon

Lire la suite…

AFPy

by AFPy - Mastodon from AFPy - Mastodon

Lire la suite…

Python 3.14 : découvrez les nouvelles fonctionnalités

by Camille Roux from Human coders

Python 3.14 entre en phase beta et apporte son lot de nouveautés ! Explorez les changements majeurs et les améliorations qui seront disponibles dans cette prochaine version du langage de programmation. Un aperçu essentiel pour les développeur·se·s Python qui souhaitent rester à jour avec les dernières évolutions du langage.

Lire la suite…

__init__.py vide ou pas

by fcodvpt from AFPy discuss

bonjour,

Sur un projet existant que je rejoins, le fichier __init__.py contient l’import des différents modules.

D’après mes ressources, il serait préférable de laisser le __init__.py vide :

1. C’est ce que l’on trouve dans le Hitchhiker’s Guide

2. Et dans cette vidéo de Brandon Rhodes à la conférence code::dive 2019 : When Python Practices Go Wrong (44e minute)

Voici ce qu’il dit :

__init__.py is a cost in the way of all the other modules that you might want to import.

Worse yet, for convenience, some __init__.py files import all their package’s module. That’s ruining the ability to cherry pick one thing you want. You can’t touch the package without waiting to load everything inside of it.

My advice, which is not what everyone would say, is to keep __init__.py empty of code

I do understand that my users don’t want to have to import things manually from all dozen of my modules, so I have “an API module” that import all of the important classes so that you can say :

from skyfield.api import xxx, yyy, zzz

J’ai retrouvé le fichier où il met ses imports : python-skyfield/skyfield/api.py at master · skyfielders/python-skyfield · GitHub

3. Cependant, un article très récent de RealPython propose exactement l’inverse. Est-ce qu’il y a des choses qui auraient changé ?

Quel est votre avis ?

Je préfèrerai partir sur un __init__.py vide et cela m’intéresse de mettre les éventuels imports dans un fichier à part mais j’ai peur que ça me mette le bazar pour la documentation Sphinx (et sphinx-apidoc mais je vois un exclude pattern)

Merci d’avance pour vos conseils.

Françoise

14 messages - 7 participant(e)s

Lire le sujet en entier

Lire la suite…

refonte mobilizon instances

by steph1978 from Linuxfr.org

Sommaire

• Pourquoi
  • Les raisons
• Design
  • exploration
  • Stack
• Productivité
  • Temps
  • Lignes de code
• Futur

Ce journal raconte la ré-écriture de l'outil Mobilizon Instances suite au passage de témoin entre Framasoft et Kaihuri.

Mobilizon Instances est outil satellite de Mobilizon, l'outil de gestion d'événements pour le Fediverse. Il s'agit du catalogue des instances que les utilisateurs ont bien voulu référencer (optin). Cela permet aux nouveaux venus de trouver une instance qui pourrait correspondre à leurs goûts.

Mobilizon Instances récolte aussi des données statistiques sur ces instances, quotidiennement, afin de les exposer.

Pourquoi

Mais cet outil existe, tourne et son code est publié, pourquoi vouloir le ré-écrire, me direz vous ?

Soyons honnête : parce que j'en ai envie ! Mais cette envie est quand même motivée par certaines raisons liées à la maintenabilité et à l'évolutivité. Car je serai probablement le seul à y toucher. Les contributeurs sont toujours bienvenus mais nous préférons concentrer les efforts sur le produit principale.

Les raisons

• Nodejs 8 ; le code n'a pas été retouché depuis des années et quand j'ai essayé de le faire tourner localement, je n'y suis pas arrivé. Soit je passe du temps à le mettre à niveau, soit j’investis ce temps dans autre chose

• Nodejs ; je n'aime pas écrire du JS/TS, encore moins en backend. Je vois l'intérêt d'un framework web quand on a un front chiadé ; nous utilisons vuejs pour Mobilizon. Ici, le cas me paraît suffisamment simple pour s'en passer. Pour le backend, j'aime beaucoup Elixir ou Python, un peu Go, un jour peut être Rust.

• Sqlpage ; j'ai déjà eu deux bonnes expériences avec SQLPage sur des projets perso. Quand on peut se permettre de rester proche des données et qu'on aime pas le frontend, c'est assez idéale. Je voulais mettre à profit cet avantage pour le cas présent.

Quand je parle de bonne expérience, je parle autant des fonctionnalités de l'outil que de sa superbe documentation et de sa bienveillante communauté. Je ne crois pas être seul.

Design

Le besoin est simple : deux écrans de consultation (liste, statistiques), un formulaire pour la proposition de nouvelle instance, et une tâche planifiée pour collecter et mettre à jour les données statistiques.

exploration

L'auteur de sqlpage est toujours disponible pour une discussion sur son produit, pour peu qu'on lui amène un cas d'usage concret.

Et cette discussion confirme mon intuition : sqlpage ne gère pas et n'a pas vocation à gérer des tâches planifiées.
J'ai donc un petit dilemme: si je dois écrire une bonne partie du logiciel avec une autre solution, pourquoi ne pas l'écrire entièrement avec cette autre solution.

Je me lance un court moment dans l'écriture du premier écran - liste des instances - en python+fastapi+pypug. Pypug en particulier, est très sympa quand on préfère une représentation à la Yaml plutôt qu'à la XML. Nous utilisons Pug dans le Mobilizon Importer.

Mais je ne trouve pas la foi d'écrire tout le code nécessaire à la simple représentation du contenu d'une table SQLite dans un tableau HTML : template avec itération, route web, DAO pour lire les données ; alors que je sais que SQLPage le fait en quelques lignes.

Stack

J'ai choisi:

• Sqlpage pour les pages web
• SQLite pour la base de données
• Python+scrapy pour la collecte des informations
• Crond (alpine) pour l'ordonnancement des tâches
• s6 pour la gestion des services
• healthcheck.io pour l'observabilité
• le tout empaqueté dans une image docker

Productivité

Temps

J'ai donc balancé tout ça dans un LLM et deux minutes plus tard … Non, je n'ai pas fait ça.

Mais, une fois n'est pas coutume, j'ai comptabilisé le temps que j'y ai passé. Je voulais me prouver que je ne passais pas plus de temps sur une ré-écriture que sur une remise à niveau.

Cela donne:

• design (1h) : le choix de la stack, le mise en place du projet, l’exploration
• import data (4h) : j'ai perdu trop de temps sur des données Json, se méfier de -> versus ->> en SQL
• écrans (4h) : efficace, avec les composants table et chart, sans surprise
• tâche planifiée (4h) : scrapy est top, vraiment peu de code à écrire, sans surprise
• packaging (3h) : peaufiner un dockerfile prend toujours un peu de temps car il faut tester
• déploiement (1h) : idem pour un docker compose
• optimisation (4h) : la vue statistiques était trop lente à mon goût, j'ai refactoré

Au total 21h, réparties sur une semaine et demie. Vous me direz ce que vous en pensez. Moi je trouve cela très correct.

Lignes de code

Autre indicateur qui m'intéressait, la quantité de code dans l'optique, le moins à maintenir, le mieux. Ça veut dire déléguer une partie de la complexité aux dépendances ; c'est le but.

• vue : 93 lignes de SQL
• job : 157 lignes de python, dont 41 liée à la migration de système
• glu : 119 lignes de shell, dont 49 liée à la migration de système

Soit 369 lignes de code, 279 si l'on ne prend pas en compte le code nécessaire à la transition depuis le système existant. À comparer aux 1737 lignes de code actuelle.

Ce chiffre est à prendre avec des pincettes car minimiser la quantité de code est un objectif qui me tient à cœur mais qui n'est pas forcément partagé. Et il manque encore des choses, qui vont venir faire augmenter ce chiffre.

J'attribue ces bons résultats - temps passé et quantité de code - au choix de la stack et à la bonne connaissance que j’en ai.

La stack prend en charge une bonne partie du travail à faire : Sqlpage pour la gestion des routes et la production du HTML+CSS+JS. Scrapy pour la gestion du parallélisme, du protocole HTTP et des ré-essais. Sans oublier s6 pour la gestion des services au sein du container.

Futur

Cette version réécrite va tourner quelques temps en parallèle de la version en production, avant une éventuelle bascule.

La vue liste mérite entre temps d'être peaufinée, avec probablement l'ajout d'un peu de styles.
Je dois aussi travailler sur le nettoyage des instances fantômes et optout, géré les défauts de réponse.

À ce stade, j'ai trouvé l'exercice très plaisant.

Hep! pas si vite ! et le code alors ?

Il est consultable ici.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Lire la suite…

AFPy

by AFPy - Mastodon from AFPy - Mastodon

Lire la suite…

AFPy

by AFPy - Mastodon from AFPy - Mastodon

Lire la suite…

Quam Facere, un gestionnaire de procédure IT (Ré-écriture)

by seraf1 from Linuxfr.org

Avant-propos

Je tiens avant tout à m'excuser pour mon précédent journal dont la forme laissait grandement à désirer.

Présentation de Quam Facere («Comment faire» en latin)

Les procédures IT sont souvent complexes et, surtout dans le cas de la gestion de cluster, elles réclament une grande rigueur dans l'écriture (tant sur le fond que sur la forme) et l'exécution (opération).
Les rédacteurs s'appliquent souvent sur le fond (bien que l'on oubli souvent les vérifications à faire entre chaque étape) mais délaissent un peu la forme (les actions à exécutées sont parfois sous la forme de balise «code», d'autres fois sous formes de citation…), ce qui peut entraîner des oublis lors de l'exécution.
J'ai donc écrit Quam Facere pour essayer de limiter ces risques.
Quam Facere ne va pas exécuter automatiquement des procédures mais va proposer une mise en forme unifiée (dans le cas des exports) ou va proposer un déroulé séquentiel avec une validation de chaque étape dans le cadre de l'exécution d'une opération.
Étant ingénieur Linux et donc plus habitué de l'utilisation de Python, j'ai développé cette application Web en Python associé à Flask et SQLAlchemy.

Fonctionnalités Clés

• Gestion de Procédures Détaillée : Supporte l'utilisation de variables et de logiques conditionnelles pour des procédures dynamiques (les tests de condition vont ensuite être intégrés à la commande à exécuter).
• Gestion des opérations : Permet le suivi de l'exécution des opérations
• Exportation de documents : divers formats, comme Mardown,PDf, Docx…
• Contrôle d'Accès Basé sur les Rôles (RBAC) : Assure une authentification et une autorisation sécurisées avec une gestion des équipes.
• Génération de Contenu Dynamique : Capacité de substituer des variables dans le contenu pour une flexibilité accrue.
• Gestion des Tâches : Découpe les procédures en étapes traçables pour une meilleure organisation.
• Internationalisation : Pour l'instant supporte l'anglais et le français.
• Compatibilité Base de Données : S'adapte aux divers systèmes gestion de bases de données pris en charge par SQLAlchemy, tels que SQLite, MySQL et PostgreSQL.

Avantages et Cas d'Utilisation

Quam Facere vise à rationaliser les opérations IT complexes, à améliorer la collaboration d'équipe et à assurer la cohérence dans l'exécution des procédures. Ses cas d'utilisation incluent :

• La standardisation des procédures pour les équipes opérationnelles.
• La documentation et l'exécution de la maintenance des serveurs pour l'administration système.
• La gestion du déploiement et de la configuration dans les workflows DevOps.
• Le maintien de pistes d'audit pour la conformité.
• La fourniture de procédures structurées pour la formation et l'intégration des équipe

Installation et utilisation

Venv

git clone git.code.sf.net/p/quam-facere/code
cd code

python3 -m venv venv
source venv/bin/activate

# For development run
flask run

# For Gunicorn wsgi run
gunicorn -w 4 -b '0.0.0.0:5000' qf:app

Docker

sudo docker load -i -q https://sourceforge.net/projects/quam-facere/files/Docker_Images/qf.tar.gz
sudo docker run -p 443:5000 -v CONFIG_PATH:/etc/quam_facere -v INSTANCE_PATH:instance qf

License

Quam Facere est disponible sous license Apache 2.0

Retour

C'est une première version Alpha de cette application et de nombreux bogues doivent encore être présents.
Vous pouvez donc faire vos retours en ouvrant un ticket sur le dépôt Sourceforge

En savoir plus et tester :

• Le site : https://qf.spn109.fr
• Le dépôt sur Sourceforge : https://sourceforge.net/projects/quam-facere/
• La démo : https://qf-demo.spn109.fr/
• Image Docker : https://sourceforge.net/projects/quam-facere/files/Docker_Images/qf.tar.gz

Commentaires : voir le flux Atom ouvrir dans le navigateur

Lire la suite…

Quam Facere, un gestionnaire de procédure IT

by seraf1 from Linuxfr.org

Bonjour à tous,je tiens tout d'abord à préciser que le résumé ci-dessous à été généré par IA (je ne suis pas très doué pour ce genre d'exercice)

Quam Facere (Comment faire en latin): L'application open source pour la gestion des procédures IT
Nous sommes ravis de vous présenter Quam Facere, une application web complète et open source conçue pour rationaliser la gestion des procédures, des opérations et des workflows d'équipe dans les environnements IT. Développée avec Flask (Python), Quam Facere vise à offrir aux équipes une solution flexible et robuste pour standardiser et suivre leurs opérations quotidiennes.

Pourquoi Quam Facere ?

Face à la complexité croissante des infrastructures IT, la nécessité de procédures claires, traçables et exécutables devient primordiale. QF répond à ce besoin en proposant :

Gestion de procédures avancée : Créez, éditez et organisez vos procédures IT avec des variables dynamiques et une logique conditionnelle. Fini les documents figés et obsolètes !

Suivi d'exécution en temps réel : Lancez des opérations basées sur vos procédures et suivez leur progression étape par étape, en temps réel.

Contrôle d'accès basé sur les rôles (RBAC) : Gérez finement les permissions des utilisateurs au sein de structures d'équipes hiérarchiques, assurant sécurité et conformité.

Export de documentation : Générez automatiquement des documents (comme des présentations PPTX) à partir de vos procédures, facilitant la communication et l'audit.

Internationalisation : L'application est déjà disponible en Anglais et en Français.

Modularité et extensibilité : Construite sur des "blueprints" Flask, QF est conçue pour être facilement adaptable et extensible.

Pour qui ?

Que vous soyez une équipe d'opérations IT, un administrateur système, un ingénieur DevOps soucieux de standardiser les déploiements, ou que vous cherchiez à améliorer la conformité et la formation, Quam Facere offre une plateforme centralisée pour structurer et exécuter vos tâches.

Participez au projet !

Quam Facere est un projet libre et open source. Nous encourageons la communauté à explorer le code, remonter les problèmes, suggérer des fonctionnalités ou même contribuer directement au développement. Votre feedback est précieux !

Pour en savoir plus et tester Quam Facere :

• Site : Site
• Code source : Dépôt GIT
• Images Docker (prêtes à l'emploi) : Image Docker

N'hésitez pas à me faire part de vos retours !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Lire la suite…