Cette documentation a pour but de fournir tous les concepts de base et le vocabulaire nécessaire pour comprendre le packaging d'applications.
Nous détaillerons ce qu'est un paquet d'applications YunoHost, comment il fonctionne, comment créer votre propre paquet et comment trouver de l'aide si vous en avez besoin.
La possibilité d'installer facilement des applications à partir d'un catalogue est une caractéristique clé de YunoHost. Alors que vous vous plongez dans le processus de packaging d'applications de YunoHost, vous devez vous souvenir de ces principes clés :
L'administrateur ne doit pas avoir un doctorat en informatique pour pouvoir installer, configurer et utiliser votre application : partez du principe que l'administrateur ne connaît pas les concepts informatiques avancés;
Less is more, Keep it simple!: ne surchargez pas l'administrateur avec une douzaine de questions techniques ;
Les choses doivent être opérationnelles dès le départ : par exemple, l'administrateur ne doit pas avoir à terminer manuellement le processus d'installation en remplissant manuellement les informations d'identification de la base de données;
Le packaging d'une application YunoHost ne se limite pas à l'installation des sources et des dépendances : il concerne également la maintenance (mise à jour, sauvegarde...) et l'intégration de l'application dans l'écosystème YunoHost (NGINX, SSO/LDAP, Fail2Ban, catalogue d'applications, UI/UX...).
Avant d'entrer dans le vif du sujet, cette documentation part du principe que :
Nous vous encourageons également à rejoindre le salon de discussion sur le packaging pour poser toutes les questions que vous pourriez avoir !
À un moment donné, vous voudrez aussi avoir un environnement de développement/test, soit en utilisant VirtualBox ou LXC/ynh-dev qui est destiné au noyau mais peut tout à fait être utilisé pour le développement d'applications. Vous pouvez également mettre en place un VPS de développement/test sur votre hébergeur préféré, ou même développer sur votre prod si vous aimez vivre dangereusement ;).
Beaucoup de choses dans YunoHost, et dans le format d'emballage de l'application YunoHost, sont historiques ou ont été conçues de manière organique. Certains aspects peuvent donc légitimement sembler anciens.
La "v0" du packaging d'applications consistait à écrire des scripts bash bruts sans réelle standardisation/contrainte.
Au fil du temps, les étapes récurrentes (comme l'installation des dépendances avec apt, ou la configuration de NGINX) ont été formalisées dans des fonctions bash standardisées, appelées "helpers". Cela a marqué le début de l'ère de la "v1" packaging.
Divers outils ont été mis en place pour tester l'application et normaliser son comportement.
Après un certain temps, un ensemble de pratiques et de conventions communes a émergé et est en quelque sorte reflété et maintenu dans l'application modèle example_ynh
. Bien qu'il soit tentant pour les développeurs de changer les schémas de nommage des variables ou de refactoriser la structure des scripts, il s'avère qu'il est encore plus important de s'en tenir à l'ensemble des pratiques communes (même si elles sont arbitraires et peu élégantes) pour faciliter la maintenance de toutes les applications par n'importe quel membre de la communauté du packaging à travers tous les dépôts !
Néanmoins, même si les aides existaient, la structure inhérente des applications était difficile et ennuyeuse à maintenir avec trop de morceaux de code redondants ou remplis de conventions historiques bizarres. Un nouveau format v2 a été conçu et ajouté à YunoHost 11.1 début 2023 dans l'espoir de moderniser et de simplifier l'emballage des applications et d'améliorer l'UI/UX de YunoHost.
Cependant, un futur format v3 est encore à venir pour simplifier davantage l'empaquetage des applications (comme la prise en charge des configurations NGINX/systemd/..., l'élimination du besoin d'écrire manuellement des scripts de suppression/sauvegarde/restauration, etc.)
Une application YunoHost est construite dans un dépôt Git. Nous vous encourageons à jeter un coup d'oeil à ces dépôts de code pour vous familiariser avec les structures des dépôts d'applications :
helloworld_ynh
example_ynh
qui contient toutes les fonctionnalités générales et le formattage recommandéParmi les fichiers contenus dans un paquet, les plus importants sont les suivants :
manifest.toml
(ou .json
dans le passé)
_common.sh
: common variables or custom functions included in other scriptsinstall
/remove
: la procédure d'installation et de suppressionupgrade
: la procédure de mise à niveaubackup
/restore
: les procédures de sauvegarde/restaurationchange_url
) : changer l'endroit où l'application est installée en termes de son url d'accès webnginx.conf
: le modèle de configuration de NGINX (=serveur web) pour cette applicationsystemd.service
: le modèle de configuration du service systemd pour cette applicationconfig.json/yaml/???
: le modèle de configuration de l'applicationGrosso modo, l'installation proprement dite se compose généralement des opérations suivantes (qui peuvent toutefois varier en fonction de la complexité et des technologies utilisées par l'application) - pas nécessairement dans cet ordre exact :
manifest.toml
.settings.yml
avec les réponses de l'administrateur au formulaire d'installationinstall
de l'application est exécuté et ses fonctions typiques sont de :A moins que vous ne souhaitiez vraiment partir de zéro ou de example_ynh
, une pratique courante consiste à identifier une application similaire à celle que vous essayez d'empaqueter - typiquement parce qu'elle repose sur les mêmes technologies - à cloner le dépôt de code correspondant, et à adapter les différents fichiers.
TODO/FIXME : here we should list a bunch of well-knowh apps for classic technologies
Vous avez découvert des erreurs ? Vous pensez pouvoir améliorer cette documentation ? Cliquez sur Éditer en haut de la page, puis sur l'icone crayon sur Github pour proposer vos changements.
Powered by Grav + with by Trilby Media. • Terms of Service