Appel a testeurs disposant d’un raspberry pi (je n’en ai pas encore), j’ai besoin de quelqu’un pour tester le bon fonctionnement d’une release cross-compilée via docker, @jytou peut être ?
j’ai mis a jours le tuto, c’est la méthode 1 qu’il faut tester :
Si ça marche je me servirai de cette méthode pour les livrables officiels, une fois que vous avez copier le binaire tout en un sur votre raspberry, voici comment tester :
Assurez vous d’avoir un noeud duniter-ts synchronisé sur votre raspberry puis lancez la commande :
./durs sync_ts
Si la sync ce passe sans erreur, lancez votre noeud :
./durs start
Vous devriez voir des connexions WS2P s’afficher dans l’interface du terminal, puis des HEADS si vous attendez suffisamment longtemps
Notamment assurez vous que dans la liste de vos connexions vous en ayez de temps en temps quelques unes en 443.
Si vous vous amusez a laisser tourner de longues heures ils se peut que le noeud plante ou se désynchronise, c’est normal c’est encore une alpha, il n’y a cependant aucun risque car c’est un noeud purement passif, il ne transmet aucune information sur le réseau a l’exception de son propre head, ce qui ne peut en aucun cas perturber le reste du réseau.
EDIT : @jytou au cas ou tu aurai déjà exécuté durs par le passé sur ton raspberry il te faut préalablement supprimer le dossier de config :
Il est désormais possible de désactiver n’importe-quel module dans la configuration (code générique).
Par exemple pour désactiver le module tui (Interface graphique dans le terminal) :
durs disable tui
Vous pouvez également lister tout les modules :
$ durs modules
tui (disabled)
ws2p
Ou lister uniquement les modules activés :
$ durs modules -e
ws2p
Enfin pour réactiver un module désactivé :
durs enable tui
La configuration est sauvegardée dans le fichier ~/.config/durs-dev/default/conf.json. Il ne faut pas modifier ce fichier a la main, car a la moindre erreur duniter-rust ne démarrera plus, utilisez la ligne de commande, l’aide est votre amie :
Ajouter des commandes de config, par exemple la commande wizard key, c’est la crate core qui gère ça tu peut t’inspiré du code existant pour les commandes enable et disable.
Ajouter des commandes a dbex (l’Explorateur de base de données)
Si besoin on peut se faire un framatalk un soir pour t’aider a te repérer dans le code
Non je ne connaissais pas celle-ci, cependant j’utilise déjà la crate clap sur laquelle se base structopt donc a mon avis il devrait être relativement facile de migrer toutes les commandes sous structopt , voila par exemple une contribution qui peut être sympa pour toi
Quel avantage de cette crate relativement a Clap ? Je trouve ca hyper élégant les commandes dans un yaml …
Autrement pour le wizard, j’ai quelques questions :
Vaut-il mieux faire un nouveau module, ou intégrer le code du wizard à tui ou à conf ?
Je comptais m’appuyer sur la crate termion pour développer le code du wizard. Est-ce que ça vous parait être une bonne idée ou est-ce qu’une autre crate semble plus adaptée ?
Alors battez vous jusqu’a e que mort s’en suive
Blague a part, je n’ai pas d’avis sur ce point, c’est vrai qu’avoir les commandes dans un yaml c’est plus facile et ça fait un point de repère pour les nouveaux contributeurs. Du coup @nanocryk quel sont tes arguments ?
Ca dépend quel wizard. Le wizard key concerne le coeur qui a forcément un trousseau. Par contre je ne prévois pas de wizard network car cela concerne les différents module.
Il serait plus propre que chaque module injecte lui même ses sous commandes de configurations. Ce qui donnera par exemple des commandes comme ws2p config et gva config. Mais l’injection c’est un peu compliqué donc je te suggère de te limiter déjà a wizard key dans un premier temps
La crate tui n’a pas a gérée la conf, c’est un module optionnel dont le seul role est de servir d’interface “graphique”. Il te faut utiliser la crate conf en association avec la crate core, comme je l’ai fait pour les commandes enable/disable qui permette respectivement d’activer/désactiver un module.
Pour le code du wizard pas besoin de termion, c’est comme prendre un semi remorque pour aller chercher une bagettte
On n’a pas besoin d’effets de console particuliers, juste de pouvoir récupérer une saisie de salt et password.
Tu défini des structures avec de la documentation classique et des annotations, et les commandes sont automatiquement générées avec la vérification des types, des options, etc. Du coup tu déclare tes structures, tu appelle structopt et tu optiens ta structure remplie si tout est bon, ou une aide générée s’il y a des erreurs (voir le README de la crate).
Du coup tu n’as besoin de connaître que le Rust et pas le YAML (alors que le format de config “officiel” de rust est le TOML), et tes structures sont autodescriptives et évite de faire manuellement tout traitement et vérifications de la ligne de commande.
Ca c’est déjà le cas actuellement avec clap. On ne vérifie pas manuellement la ligne de commande.
Donc les “gains” de structopt vs clap seule sont faibles. Quand au YAML c’est le format que j’ai choisi mais clap supporte aussi le TOML donc la aussi ce n’est pas un argument recevable.
Ceci étant structopt réduit les sources de bug car avec clap quand je match si la commande toto a été saisie le compilateur ne peut pas vérifier si toto est une commande existante, donc des erreurs de frappe peuvent se faufiler.
@nanocryk j’ai quand même une question : est ce que structopt permet l’injection de sous commandes par des plugins ? De sorte que le coeur qui déclare la Struct ne peut évidemment pas connaitre les sous commandes injectés. Parce que ça clap seule sait le faire, et c’est un besoin !
Aïe ça sent pas bon. Il faut que chaque plugin puisse injecter sa sous-commande (au moins une, elle pourra elle même contenir autant de sous-commandes que nécessaire). En lisant la doc de structopt je ne vois rien a ce sujet, si l’injection n’est pas possible alors il nous faudra rester sur clap seule.
Le fait que ne sache pas (car je ne l’ai jamais fait) ne veux pas dire que ce n’est pas faisable. J’ai vu notament que l’on peut récupérer la structure clap générée par structopts, donc on peut peut écrire du code pour les “combiner entre elles”.
En effet je viens de voir les fonctions clap et from_clap dans la doc,( je n’avais pas encore eu le temps de tout voir) donc on peut injecter les clap::App des différents plugins, donc tout est parfait
EDIT : Pour l’injection faudra modifier le trait DuniterModule (que je doit d’ailleurs renommé ,en DursPlugin) pour y ajouter une méthode retournant une clap::App. Et faut que le core appelle cette méthode pour chaque plugin pluggé afin d’agréger les Clap::App. Tu te sent de le faire ?
