Effet boomerang pour les contributions à du logiciel libre

Lorsqu’on corrige une anomalie ou qu’on a ajoute une fonctionnalité à un logiciel ou une bibliothèque, on peut la garder pour soi ou la partager. La deuxième solution demande un peu plus d’efforts à court terme mais est préférable à long terme.

Le délai de retour d’un correctif ou d’une amélioration dépend de l’endroit où il est proposé : plus il est poussé loin et plus il va mettre de temps à revenir mais le nombre de personnes/machines bénéficiant du correctif sera plus grand.

Les différentes possibilités

Gardé pour soi

Cette méthode est absente du schéma puisqu’elle consiste à ne pas envoyer la modification à l’extérieur. C’est le plus rapide à mettre en œuvre, d’autant plus que la qualité du correctif n’est validée qu’en interne (juste soi-même ou par l’équipe intégrant la modification). Diverses façons d’arriver à ses fins sont possibles comme surcharger la signature de la méthode qui pose problème, attraper l’erreur non traitée correctement, intégrer la bibliothèque dans le code et la modifier directement (vendoring), etc.

Par contre, personne d’autre ne bénéficie du correctif et personne d’extérieur ne fera une revue de code.

Publication solitaire

La vitesse de mise au point est équivalente à la méthode précédente. Le déploiement prend un peu de temps. Elle permet de rendre la modification disponible pour les autres utilisateurs s’ils la trouvent. Ce phénomène est visible avec l’incitation au fork proposée par les forges comme Github, Gitlab, Bitbucket, etc, sans pousser la modification vers le développeur amont (via une pull request). Cette technique est utilisée lorsque des développeurs :

1. forkent un dépôt,
2. créent un commit modifiant le nouveau dépôt,
3. font dépendre leur application de ce commit (npm install git+https://alice@forge...).

Cependant, ce comportement n’est pas limité aux forges publiques : il existait déjà avant en publiant le correctif dans un article de blog, une liste de diffusion (liste non exhaustive).

Envoyé vers la distribution

La correction est envoyée dans la distribution Linux utilisée ; c’est souvent fait en incluant la modification dans un fichier, attaché à un rapport de bogue sur la distribution.

Une fois que la modification sera intégrée et qu’un nouveau paquet sera publié, l’ensemble des utilisateurs, y compris l’auteur, en bénéficieront. Cela évite de maintenir la modification de son côté lorsque de nouvelles versions du paquet seront publiées. La durée d’intégration est plus longue selon la réactivité du mainteneur du paquet et le mode de publication (version espacée ou rolling release). Bien évidemment, le bénéfice de la modification sera perdu en cas de changement de distribution.

Cette solution est nécessaire pour corriger/améliorer un élément spécifique d’un paquet de la distribution. Cela peut arriver dans deux cas :

• soit parce que c’est un paquet spécifique à la distribution (le paquet apt pour debian par exemple)
• soit parce qu’une modification du logiciel spécifique à la distribution a une influence sur la modification soumise

Envoyé vers le développeur amont

Plutôt que d’envoyer le correctif vers la distribution utilisée, il est alors envoyé directement vers le développeur du logiciel. Si le développement est hébergé sur une forge publique, cela suppose le faire un fork (comme dans le cas d’une publication solitaire), puis de faire une pull request (terme Github), merge request (terme Gitlab). Sinon, il faut regarder quelle est la forme attendue : en postant sur une liste de diffusion, ou directement vers le mainteneur, etc. Il sera nécessaire de répondre aux remarques et demandes de corrections pour que la modification soit intégrée dans le logiciel amont.

Comme dans le cas d’une intégration dans la distribution, une fois intégrée, la modification sera disponible pour tous :

• soit en réutilisant le logiciel directement via le paquet issus du langage (par exemple gem pour ruby, wheel pour python, crate pour Rust, etc.)
• soit parce que la version du logiciel sera elle aussi intégrée dans la distribution et donc obtenue dans un paquet de la distribution

Ce type de contributions sont les plus longues à revenir au contributeur mais elles permettent le déploiement le plus large (et donc la plus grande disponibilité pour soi et pour les autres).

Autres considérations

S’il n’est pas possible d’attendre le retour de la modification, la solution optimale est de faire un correctif local et un envoi vers la distribution ou vers le développeur amont (pour qu’une solution long terme soit aussi disponible automatiquement).

Pour bénéficier de l’envoi amont, il faut que le temps de retour soit inférieur au temps de changement de techno/bibliothèque. Dans un écosystème où les outils et bibliothèques sont abandonnés très rapidement, l’effort d’intégration peut être perçu comme vain puisque la personne ayant fait le développement aura peu le temps d’en profiter. D’un point de vue général, avec une majorité de personnes faisant ce calcul, cela ne fait qu’empirer le problème, avec des multitudes de fork s’ignorant mutuellement, chacun avec une fonctionnalité ou une correction différente. Javascript me semble être dans cette situation.

À propos du schéma

Le schéma a été réalisé avec Dia, installable par le paquet du même nom pour Debian et dérivées.
Fichier source .dia

How to self-host Expo webapp with Apache 2.4

This short howto comes from a github pull request not merged.

1. Build your Expo web app

Use the command provided by expo:
$ expo build:web

2. Provide the web-build/ directory to the server

Several ways are available according to your workflow.

For example:

• copy the web-build/ directory to /path/to/web-build/ on the server with scp or sftp commands. `ssh` server is required on the server. Create distant path (/path/to/) before copying web-build/ directory.
• configure Continuous Integration to build and deploy the web-build/ directory.

3. Configure Apache webserver

Apache will host the generated static files.

Create a file at /etc/apache2/sites-available/expo.conf with:

<VirtualHost ip-server:80>
    ServerAdmin your-email@address.tld
    ServerName domain-for-the-app
    Alias / /path/to/web-build/
    <Directory /path/to/web-build/>
            Require all granted
    </Directory>
</VirtualHost>

You have to change ip-server, your-email@address.tld, domain-for-the-app and /path/to/web-build/ according to your setup.

• ip-server: IP used by the server to receive requests from the clients
• your-email@address.tld: e-mail address shown to the client if a server error occurs
• domain-for-the-app: domain where the files are served to the client. When users go to `http://domain-for-the-app` with a browser, the app will be loaded
• /path/to/web-build/: path where the web-build/ directory is

4. Enable the new VirtualHost


$ sudo a2ensite expo


5. Restart Apache


$ sudo systemctl restart apache2


6. It works!

Check that the webapp is available at domain-for-the-app with a browser.

Configuration(s) grâce à ConfigParser

configparser est un module de la bibliothèque standard Python permettant de lire ou d’écrire une configuration. C’est utile pour séparer code source et paramètres. D’autres solutions sont possibles comme du json (disponible dans la bibliothèque standard) ou, en utilisant des bibliothèques tierces disponibles sur pypi.org, du yaml voire toml (pour ceux qui veulent le dernier truc à la mode).

La classe configparser.ConfigParser() permet de lire différentes sources (une chaîne de caractères, un fichier ou un dictionnaire) mais aussi d’écrire des configurations dans un fichier.

conf = """
[batman]
talent = riche
"""
import configparser
config = configparser.ConfigParser()
config.read_string(conf)
# config["batman"]["talent"] vaut "riche"

with open('superheros.ini', 'w') as f:
    config.write(f)
# le fichier superheros.ini contient les données de Batman

Un aperçu plus large des possibilités est présenté dans l’introduction du module.

Possibilité moins connue, ConfigParser peut lire plusieurs configurations successives. Les données lues écrasent les données précédentes ; les données non modifiées restent.

Supposons une initialisation avec un dictionnaire:

PAR_DEFAUT = {
    "superman": {"talent": "vole avec son slip sur son pantalon"},
    "kleptomane": {"talent": "vole des petites cuillères"},
}

ConfigParser peut charger cette configuration avec la méthode read_dict().

config = configparser.ConfigParser()
config.read_dict(PAR_DEFAUT)
# config['superman']["talent"] vaut "vole avec son slip sur son pantalon"

• le comportement d’une instance de ConfigParser() ressemble à celui d’un dictionnaire
• les données sont obligatoirement dans une section (batman, superman, kleptomane)
• les valeurs sont toujours des chaînes de caractères

Ces valeurs par défaut pourraient être écrasées par un fichier de configuration. Le format de fichier attendu est de type .ini.

Avec un fichier de configuration /etc/heros.ini contenant:

[superman]
talent=vole sans être décoiffé


config.read("/etc/heros.ini")
# config["superman"]["talent"] vaut maintenant "vole sans être décoiffé"
# config["kleptomane"]["talent"] est inchangé

Évidemment, les noms doivent être impérativement identiques aux valeurs par défaut pour qu’elles écrasent la valeur précédente et non qu’elles co-existent et soient ignorées par la suite.

Il est possible de redéfinir à nouveau la configuration avec d’autres fichiers (~/config/superheros.conf par exemple) en faisant de nouveaux appels config.read(). Idem avec config.read_dict() ou config.read_string().

Le comportement d’écrasements successifs des données n’est pas explicite dans la documentation Python mais une amélioration de la documentation est en attente.

Suppression automatique de fichiers

Il est pratique d’automatiser la suppression des fichiers dont on ne se sert plus. Trois astuces complémentaires pour réaliser cela sur un ordinateur de bureau :

Écrire dans /tmp

Étant donné que le répertoire /tmp est vidé au démarrage de la machine, faire ses essais dans ce répertoire évite d’avoir à les supprimer manuellement.

Vider la corbeille de bureau

Sous Debian et dérivées, installer le paquet trash-cli et ajouter la ligne suivante dans sa crontab :

15 13 * * * trash-empty 30

Ainsi, tous les jours, à 13h15, les fichiers placés dans la corbeille depuis plus de 30 jours seront supprimés.
Cela fonctionne avec tout environnement de bureau respectant Freedesktop (Gnome, KDE, etc.).

Supprimer des e-mails automatiquement

Thunderbird permet de supprimer des e-mails en fonction de leur âge. Pratique pour les répertoires comme la corbeille, le spam ou certains répertoires dont le contenu n’a plus d’intérêt avec le temps.
Faire un clic droit sur le répertoire à nettoyer automatiquement et cliquer sur Propriétés :

Cette possibilité n’est pas une exclusivité de Thunderbird, il existe des équivalents dans d’autres clients e-mails.

Voilà, il ne reste plus qu’à automatiser la création des fichiers et recevoir un peu plus de spam ! 😉

Greffons Firefox pour Python

L’usage quotidien de Python est facilitée par l’ajout de quelques moteurs de recherche à Mozilla Firefox.

Firefox propose deux affichages différents pour les barres d’adresse et de recherche : soit séparée (c’est le mode historique), soit dans le même champ (c’est l’équivalent du comportement de Google Chrome/Chromium).

Selon le mode d’affichage choisi, l’utilisation est différente. Après avoir vu l’usage des extensions avec la barre d’adresse séparée du champ de recherche, la façon d’utiliser les extensions avec la barre unifiée sera abordée.

Extensions

Python Search

Python Search ajoute un moteur de recherche permettant de rechercher directement dans différentes documentations python3 (bibliothèque standard, API C, glossaire, etc).

Les moteurs de recherche ajoutés (ce qui inclut donc Python Search) ne sont pas visibles dans les extensions mais sur la page about:preferences#search.

Python Doc

Python Doc répond au même besoin que Python Search mais utilise un bouton pour faire la recherche plutôt que l’interface de recherche classique de Firefox. Il faut d’abord cliquer sur le bouton pour avoir le champ où saisir sa recherche. Cela peut être utile si on l’utilise peu car la présence du bouton rappelle automatiquement la disponibilité de la recherche.

Python Doc est visible dans la liste des extensions (accessible par about:addons dans la barre d’adresse ou, selon les versions, en cliquant sur Extensions ou Modules supplémentaires).

PyPI

PyPI ajoute un moteur cherchant dans la liste des paquets disponibles sur pypi.org.

Comme Python Search, il sera visible sur la page about:preferences#search une fois installé.

Recherche dans la barre de recherche unifiée

Il est possible d’ajouter un raccourci vers un moteur de recherche dans les Préférences du navigateur. Dans ce cas, il suffit d’utiliser le raccourci avant sa recherche pour sélectionner le moteur de recherche à utiliser.
Par exemple, en saisisant @py datetime, Firefox affichera la page de résultat de la recherche de datetime sur le site de la documentation de python. Cela est donc faisable pour Python Search et Pypi (pas Python Doc).

Raccourcis pour PyPI et Python Search

Bonus : créer d’autres moteurs de recherche

L’ajout de moteur de recherche intégré à Firefox (comme Python Search et PyPI) est simple à développer. La base est la préparation d’un fichier XML décrivant la recherche à faire (format de la requête, méthode, etc.). Le XML est trop court pour être douloureux (tant mieux ou tant pis, selon les goûts).

Outils utilisés

Pour afficher la capture de sélection du moteur à la souris, il n’était pas possible de faire une capture d’écran, car la perte du focus ferme la sélection. Pour cela, un enregistrement vidéo a été fait avec SimpleScreenRecorder, puis l’image adéquate a été extraite avec Kdenlive.

Aucun navigateur n’a été maltraité lors de l’écriture de cet article.