Packager Cagette.net

Salut,
je lis plein de postes et sujets sur comme organiser la communauté Yuno autour des apps et issues, mais je reconnait que pour un débutant absolu comme moi… c’est pas claire.

J’ai réussi il y a peut grace à @Maniack_Crudelis et @scith ainsi que le dev bablukid de l’app à l’installer sur mon instance.

Le jeu pour moi consisterait, dans l’aventure de l’auto-hébergement, à contribuer modestement en rendant possible l’installation via l’interface admin web.
J’ai d’ailleurs jeté les premières fondations ici (faut bien commencer)
je découvre en fait git … et Github… et prend donc la mesure de tous le travail qui est fait par vous cher codeurs et contrib de tous poils.

whaou !

comme je démarre, je me pose plein de questions :

  • comment faire pour pour bien sourcer dans le package les releases de l’app? (forker l’app, créer un nouveau repo ? …)
  • comment faire partie de l’orga yuno sur git ? (mêmesi je crois comprendre que tous cela devrais migrer sur gitlab !!?? )
  • ai-je intérêt a comprendre tous de suite le fonctionnement du package_checker de suite ? (sachant que je ne sais pas si je vais maintenir l’app longtemps ? ou si le dev pourra le prendre en chargé une fois op ? )

voilà :wink:

En la matière les pratiques ne sont pas uniformes, mais un point ressort, on ne duplique pas l’app dans les dépôts sous forme d’archive. Pour éviter de créer des gros dépôts.
Tu as dupliqué l’app directement, c’est une solution.

Pour ma part je recommande de télécharger l’app et de vérifier sa somme de contrôle pour s’assurer de son intégrité. Cela évite de grossir inutilement ton dépôt, et te permet de figer la version de l’app installée.
J’utilise cette fonction qui se basent sur ces fichiers. Tu es bien sûr libre de simplifier ça.

Tu pourras faire un “Transfer ownership” dans les settings de ton dépôt quand tu le désireras. Je t’ai envoyé une invitation pour intégrer l’orga.

Il n’y a pas grand chose à comprendre, si tu souhaites l’essayer, il suffit de suivre les étapes d’installation du readme, dans une machine virtuelle de préférence. La même qui te sert pour tester ton package actuellement (car bien sûr tu travailles dans une machine virtuelle, tu n’es pas assez fou pour travailler sur ton serveur de prod).

Package_check est une aide au packaging, pour t’assurer que ton package fonctionne bien. Ce n’est pas une contrainte, si il te semble trop compliqué, tu n’es pas forcé de l’utiliser.

Par contre, c’est mieux si tu peux maintenir ton app sur la durée. Car c’est cool de la packager pour les autres, tu feras des heureux. Mais si dans 2 mois elle marche plus, t’auras fais ça pour rien, ce serais dommage…

Salut, je complète ce que dit Maniack avec quelques tips que j’utilise.
J’ai découvert “bash”, “git” et tous ces trucs avec YunoHost aussi il y a quelques années. Je package pas mal même si je pense avoir gardé quelques (mauvaises ?) habitudes de débutant. Mais si ça peut servir :slight_smile:

Voilà comment je fais pour un nouveau projet de package:

  1. Je crée un dépot sur Github (par exemple cagette_ynh) de zéro, et je le clone dans mon ordinateur
  2. Je télécharge le zip de l’application example_ynh
  3. J’extrais le zip dans le dossier de mon app: ca y est, j’ai le “squelette” !
  4. Je modifie le fichier manifest.json: Je change l’id, description, nom mainteneur, … Puis je retire les options qui ne me servent pas ou en ajoute éventuellement ( bien faire attention à ce que la dernière option n’ait pas de virgule à la fin)
  5. Je m’attaque ensuite au fichier install: Je retire les arguments inutilisés au début ainsi que les paragraphes qui ne servent pas à l’app (souvent la partie PHP FPM). SI l’app utilise MySQL, je décommente les lignes appropriées. Ensuite le gros du travail se fait dans la partie “copy source files” qui est à ajuster
  6. Vient ensuite le fichier upgrade. Il est à modifier pareil que l’install. Je copie/colle juste les choses que j’y ai modifié
  7. Le fichier remove, backup et restore restent en général très similaires. Il faut surtout décommenter ce qu’il te faut

Pour les sources, tu peux soit les télécharger manuellement et les mettre dans le dossier “sources”, soit faire ça dans le script install. Par exemple avec “sudo wget URL-vers-les-sources” puis dézipper dans les dossiers.
En général pour m’aider je regarde le code des apps qui marchent et que j’utilise déjà.

Ensuite il faut envoyer toutes tes manipulations sur github, et puis essayer d’installer l’app avec l’option “–verbose” pour voir ce qui marche pas. “sudo yunohost app install lien-vers-github --verbose”

Je te recommande de faire ça sur un ordinateur de test (comme un raspberry pi de rechange), ou dans une “machine virtuelle” (par exemple sous “virtualbox”). Si tu as un raspberry, tu peux éventuellement acheter une 2nd carte SD, y installer YunoHost et intervertir les cartes SD pour avoir un raspberry pi “de test” sur lequel éventuellement tout casser :laughing:

Ensuite pour package_check oui c’est intéressant mais peut-être plutôt dans un second temps. Les étapes que je décris ci-dessus ne requierrent presque pas d’usage du terminal, il faut juste savoir bidouiller un peu les scripts d’exemple.

Bon courage, n’hésite pas si besoin :slight_smile:

merci à vous pour ces précisions; de mon coté, mon serveur un Nuc sous debian 8 avec vitualbox qui fait tourner une instance yuno… et c’est vrai que du coup, j’ai tendance à faire les tests direst sur la disto en production… my bad :smiley:

je tacherais de faire les tests sur une autre machine vituelle donc genre yunolive .

Travailler sur ton serveur de prod est à proscrire pour 2 principales raisons :

  • Toutes les essais que tu vas faire vont laisser des résidus sur ton serveur, et si tu casses quelque chose pendant tes essais, tu casses ton serveur de prod…
  • Les résidus que tu laisses ainsi que les paquets que tu as installé auparavant pour d’autres applications font que ton serveur n’est plus représentatif d’une instance Yunohost de base. Donc même si ton package est fonctionnel chez toi, il ne sera peut-être pas chez les autres car il manquera peut-être une dépendance ou une action diverse qui aura laissé des traces sur ton serveur.

Pour la seconde raison évoquée, travailler sur un raspi de test n’est pas une bonne idée si tu ne disposes pas d’un snapshot à restaurer régulièrement.
Ton instance de test doit toujours rester une instance Yunohost vierge de toute autre installation.