État d'avancement de Durs (Dividende Universel Rust)


#21

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 :

https://duniter.org/fr/wiki/duniter-rs/cross-compilation-pour-arm/

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 :

  1. Assurez vous d’avoir un noeud duniter-ts synchronisé sur votre raspberry puis lancez la commande :

    ./durs sync_ts

  2. 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 :slight_smile:
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 :

rm -rf ~/.config/durs-dev

#22

La documentation du code de Duniter-Rust est publiée via la CI gitlab ici :

https://nodes.duniter.io/rust/duniter-rs/durs/


#23

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 :

durs --help

#24

\o/ pu**** je suis plutôt fier de moi, 2 grosses avancés aujourd’hui :

  1. Cross-compilation de duniter-rust pour windows dans docker
  2. Exécution dans wine des tests automatisés sur le binaire windows (aussi dans docker) !!

Pour le point 1, je vais avoir besoin de quelqu’un sous window pour vérifier que le binaire final fonctionne bien, @nanocryk peut-être ?

Pour tester:

  • Télécharger l’artifact ici : https://git.duniter.org/nodes/rust/duniter-rs/-/jobs/7787 (cliquez bouton download)

  • Extraire l’archive puis dans work/bin/ extraire la 2ème archive qui contient durs.exe

  • Ouvrir une console windows

  • Exécuter directement durs.exe en testant quelques commandes :

    durs.exe --help
    

doit afficher l’aide.
Si vous avez un noeud duniter-ts synchro sur votre windows vous pouvez tester la sync :

durs.exe sync_ts

Vos retours me serait très précieux, merci :slight_smile:

Pour les curieux, l’image docker est là : https://git.duniter.org/docker/rust/win64-builder


#25

Je vois que tu touches encore beaucoup en profondeur au code de WS2Pv2.

Tu vois des tasks durs simples et qui demandent pas trop de temps ?

J’aimerai bien prendre 1h ou 2 par ci par là pour coder un peu en Rust quand je trouve du temps…


/!\ Significant : RFC WS2P V2 /!\
#26

Ce que je vois de plus simple :

  • 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 :wink:


#27

Est-ce que pour les commandes tu utilise la magnifique crate structopt ? :slight_smile:

Sinon je me remettrais bien à contribuer un peu, tu as quelque chose chose de sympa à me proposer ?


#28

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 :blush:


#29

Super, ça serait un plaisir de faire un peu de structopt :smiley:


#30

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 ?

#31

Alors battez vous jusqu’a e que mort s’en suive :rofl::joy:
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 :slight_smile:

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 :sweat_smile:
On n’a pas besoin d’effets de console particuliers, juste de pouvoir récupérer une saisie de salt et password.


#32

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.


#33

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.

Donc si ça te fait plaisir fait le :slight_smile:


#34

Yeap, on pourra en débattre dans la Merge Request :stuck_out_tongue:

Et puis bon, si ça me permet de me remettre un peu à contribuer à durs alors que je suis celui l’ayant initié à la base xD


#35

@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 !


#36

Aucune idée, ça sera l’occasion de le découvrir.

Je sais que l’on peut gérer les sous-commande avec une Enum, mais peut-être qu’il est possible de les “injecter” manuellement.


#37

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.


#38

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”.


#39

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 :slight_smile:

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 ?


#40

Je vais regarder ça, et si des trucs ne vont pas on en discutera dans la MR ? :slight_smile: