Manifest mal écrit, mais comment débugger?

Bonjour,

Je suis en train de packager une application simple.
J’ai rédigé le manifest en v2 et en v1 (pour le tester sur ma machine qui est encore en Yunohost 11.0)

J’en suis à la phase de test.
J’utilise d’abord le test manuel en ligne de commande:

sudo yunohost app install https://github.com/chemin-vers-mon-app

Malheureusement, ça plante à l’analyse du fichier manifest:

manifest[“arguments”][“install”] = install_arguments
KeyError: ‘arguments’

Existe-t-il un fichier log qui pourrait me donner plus d’infos?

Merci d’avance

Ça semble juste indiquer qu’il n’y a pas de clef arguments dans ton manifest, donc il n’y a pas vraiment plus d’info magique à te donner, il faudrait surtout regarder dans ton manifest …

Bonjour @Aleks,
Merci de ta réponse.
J’ai justement une clé arguments , car j’ai repris le modèle de manifest.toml.
Dans le doute, j’ai aussi repris un modèle manifest.json car ma version de Yunohost est 11.0 et utilise surement le packaging v1.
Donc en l’absence de log, je suis coincé. Je ne sais pas sûr que mes fichiers sont bien téléchargés.

D’ailleurs je viens de faire une manip où je copie le manifest.json d’une autre app publiée que j’arrive à installer. Quand je copie son manifest.json vers mon Git, j’obtiens la même erreur.

J’en déduis que Yunohost ne récupère pas mes fichiers;
Sais-tu vers quel répertoire ils sont supposés être téléchargés?

Tu dois avoir des logs pour ta tentative d’installation ratée quelque part la dedans: sudo yunohost log list
Après tu peux les partager avec sudo yunohost log share <name>
Mais le plus simple pour t’aider serait de nous partager le repo de ton app…

Et pour répondre à la question du titre : tu peux utiliser package_linter pour avoir des indications sur les erreurs dans ton paquet.

1 Like

Bonsoir @Tagada et merci de ton aide.

J’avais déjà utilisé package_linter et modifié mon code pour être conforme.
Il est ici; appli Webdav

Il n’y a aucun log avec la commande que tu proposes. Et je me suis connecté en ssh, je n’aii rien trouvé dans /var/log
C’est bien dommage…
j’ai par ailleurs constaté que les fichiers sont bien téléchargés , ils sont dans un répertoire de

/var/cache/yunohost/app_tmp_work_dirs

J’ai donc pu avancer dans la résolution du problème: il semble y avoir une erreur de code dans le fichier python de yunohost qui récupère le manifest de l’application

Voici pourquoi:

J’ai affiché le code du dernier fichier python qui plantait, à savoir

/usr/lib/python3/dist-packages/yunohost/app.py
line 1884, in _get_manifest_of_app 

Le code est le suivant:

if os.path.exists(os.path.join(path, "manifest.toml")):
        manifest_toml = read_toml(os.path.join(path, "manifest.toml"))

        manifest = manifest_toml.copy()

        install_arguments = []
        for name, values in (
            manifest_toml.get("arguments", {}).get("install", {}).items()
        ):
            args = values.copy()
            args["name"] = name

            install_arguments.append(args)

        manifest["arguments"]["install"] = install_arguments

    elif os.path.exists(os.path.join(path, "manifest.json")):
        manifest = read_json(os.path.join(path, "manifest.json"))
    else:
        raise YunohostError(
            f"There doesn't seem to be any manifest file in {path} ... It looks 
like an app was not correctly installed/removed.",
            raw_msg=True,

D’après ce code, on cherche d’abord le manifest.toml, on le recopie; Et s’il n’existe pas, alors on cherche le manifest.json .
Or mon fichier manifest.toml est une copie presque conforme de l’exemple donné ici
example_ynh

J’avais prévu le coup en préparant aussi un manifest.json qui devait fonctionner.

Il faudrait modifier le code de app.py pour lire le json si jamais la lecture du toml plante. Mais ça ne résoudra pas le problème pour les serveurs qui sont en Yunohost <= 11.1

Donc il faudrait préciser au packageurs de ne pas faire coexister le manifest.json et le manifest.toml

Et d’ailleurs, j’aimerais bien comprendre comment on fait pour packager une application pour Yunohost <11.1 et Yunohost >11.1.
Faut-il 2 branches? Comment le serveur trouve-t-il le bon catalogue?

Il n’y a pas à avoir deux manifest, ça n’a pas de sens, ce serait comme avoir deux cartes grises pour ta voiture, au cas où il y a une typo dans la première … c’est confusionant et ça sert à rien, il faut juste ne pas faire de typo. Si tu fais une nouvelle app, alors il faut écrire ton app en format v2, c’est à dire avec un manifest.toml, car c’est la recommendation et le format v1 est destiné à disparaître.

Il n’y a pas à packager des apps pour des vieilles versions … les gens sont censés tenir leur serveurs à jour. Éventuellement ça peut se discuter de maintenir temporairement une compatibilité entre versions majeurs, disons quand la transition 4.x Buster->11.0 Bullseye est “en cours” (mais ce n’est plus vraiment le cas, Bullseye est supporté depuis déjà un an, et Debian a déjà sorti Bookworm). Pour 11.0 vs 11.1, il n’y a pas spécialement de raison qui empêchent les gens de faire la mise à jour rapidement.

1 Like

C’est étrange… Tu n’as vraiment rien dans sudo yunohost log list ?
Ça serait chouette d’avoir les logs de “pourquoi ton manifest.toml ne marche pas”, car c’est ça le vrai problème ici.

Perso si je supprime le manifest.json et que je renomme _manifest.toml en manifest.toml puis tente une install j’ai :

249  ERROR Invalid size suffix 'k', expected one of ('K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y')

Qui corresponds à ram.build et .runtime dans le manifest qui est 100k. Si je met 1M je n’ai pas de soucis, YunoHost me pose la question à propos du domaine, donc pas de soucis de parsing de manifest … je ne comprends pas où est le problème

Je voulais faire 2 manifest, un en json pour ma version 11.0, et un en toml pour ma version 11.1 quand j’aurai fait la mise à jour.
Je suis prudent sur les mises à jour, car j’ai déjà eu des plantages avec des bugs lors de mises à jour précédentes. Donc j’'attends les moments où j’ai du temps (par exemple les grandes vacances ou la période du nouvel an), pour prendre le temps de récupérer mon serveur en cas de plantage. Il m’est arrivé d’y passer près d’une semaine…

Cette commande ne me donne qu’un rapport sur la création des backup

@Aleks:
Chez toi ça fonctionne parce que tu es en 11.1
Chez moi, en Yunohost 11.0, le code de app.py, que j’ai collé plus haut, ne fonctionne pas car on est censé trouver une clé “arguments” dans le manifest.toml. Or, en packaging v2, cette clé n’existe plus. Elle était bien présente dans manifest.json.
D’ailleurs on voit bien que le code a changé au passage de Yunohost 11.1:
nouvelle fonction “_get_manifest_of_app” dans app.py

  if os.path.exists(os.path.join(path, "manifest.toml")):
        manifest = read_toml(os.path.join(path, "manifest.toml"))
    elif os.path.exists(os.path.join(path, "manifest.json")):
        manifest = read_json(os.path.join(path, "manifest.json"))
    else:
        raise YunohostError(
            f"There doesn't seem to be any manifest file in {path} ... It looks like an app was not correctly installed/removed.",
            raw_msg=True,
        )

    manifest["packaging_format"] = float(
        str(manifest.get("packaging_format", "")).strip() or "0"
    )

    if manifest["packaging_format"] < 2:
        manifest = _convert_v1_manifest_to_v2(manifest)

Je pense d’ailleurs que le descriptif de cette fonction est erroné. Il ne correspond pas au schéma retenu pour manifest.toml puisqu’il n’y a plus de clé “arguments”

Moui bon du coup le fond du probleme c’est pas que y’a un probleme dans YunoHost, le probleme c’est que tu essayes de contourner le fait que tu es en 11.0 en utilisant l’ancient format de packaging … Moi je te dirais que il faudrait juste prendre le temps qu’il faut pour faire la montée de version, qu’il faudra toujours finir par faire, plutôt que de coder un truc déjà obsolète qu’il faudra ensuite convertir dans le nouveau format …

L’exemple de manifest dans le code est effectivement pas forcément à jour, mais bon en même temps c’est pas non plus destiné à être une documentation du format du manifest, qui est documenté ailleurs …