Edit j’ai remplacé le contenu par la release 0.7.0 et renommé le post
Je viens de faire une “release” de g1cli 0.7.0.
En résumé en français, ce qui change (les détails sont en anglais plus bas):
Nouveau nom de package et de commande g1cli
La configuration et la base de donnée du vault ne sont plus dans le même répertoire, possibilité de copier les données de l’ancien gcli si nécessaires (voir détails plus bas)
Améliorations vault vanity
Affichage de la probabilité de trouver une adresse correspondant au pattern (peut être incorrect; surtout pour les regex)
Affichage du nombe de clés générées et nombre moyen de clés générées par seconde
Modifications des paramètres (voir détails plus bas)
Support de recherche basée sur une expression régulière
Un exemple d’usage est donné dans les détails plus bas
Configuration du runtime g1 (devrait être la version finale)
Question pour les personnes sous MacOS; est-ce que quelqu’un pourrait vérifier si le Homebrew Formula qui a été déployé est bien correct (premier test depuis le changement de nom de package !)
[0.7.0] - 2026-03-02
Added / Changed
The project gcli has now been renamed to g1cli so that it could be registered as an official package in Debian and Homebrew.
This means the package and the command have been renamed to g1cli
Also, the configuration and vault database from oldgcli is not migrated with this change, because the new package names means new folders as well
~/.config/g1cli/ containing the configuration in file default-config.toml
~/.local/share/g1cli/ containing the vault database in file g1cli.sqlite
If for some reason you want to retrieve data from old installation, you can find the files at this location (you can copy/move them to the new path & name if you want)
/.config/gcli/default-config.toml
~/.local/share/gcli/gcli.sqlite
One command to retrieve config & vault database from gcli to g1cli ( overrides what you may have already added in g1cli):
estimated probability of finding a key matching the pattern (still experimental and can be very inaccurate for now, especially for regex patterns)
elapsed time, number of keys generated, average number of keys/s and EstimatedTime to find a match (refreshed every 5 seconds)
shows the actual Time/match at the end of the search (unless stopped manually)
Adapted the parameter names and shortcuts to be more consistent
--pattern (shortcut -p instead of old-m)
--match-mode (shortcut -m) instead of old--position (shortcut -o)
Adapted the possible values for this argument to be more consistent:
startswith instead of oldstart
contains instead of oldany
endswith instead of oldend
newregex to allow providing a Regular Expression pattern where position is expressed within the regex itself (e.g. ^g1..Ni for start, Ni$ for end, Ni for any)
Example — case-insensitive regex search for “nico” in an SS58 address: use the (?i) inline modifier at the start of the pattern to make the regex case-insensitive.
# Ongoing search:
g1cli vault vanity -p "(?i)nico" -m regex -s 5 -t 8
Running search with 8 threads
Estimated probability: ~1 in 65,793 attempts (approximate)
- execute prize shove rotate two extend naive grit north suffer gift vibrant (address: g1LWzN4pdrtKe3Xby4nicoaztUfLvxoLjBiH1okiH9N9twNYx)
- market region student patient impose grocery glass below blossom laptop police bronze (address: g1Q3NvKGzniCoR3QdV1h523pGZsiYQTYYVQULJFPfskeERL3H)
Elapsed: 5.0s | Keys generated: 40,802 | avg: 8159 keys/s | ET/match: ~8.1s (approx)
# When search is completed, showing actual Time/match:
g1cli vault vanity -p "(?i)nico" -m regex -s 5 -t 8
Running search with 8 threads
Estimated probability: ~1 in 65,793 attempts (approximate)
- execute prize shove rotate two extend naive grit north suffer gift vibrant (address: g1LWzN4pdrtKe3Xby4nicoaztUfLvxoLjBiH1okiH9N9twNYx)
- market region student patient impose grocery glass below blossom laptop police bronze (address: g1Q3NvKGzniCoR3QdV1h523pGZsiYQTYYVQULJFPfskeERL3H)
- mistake proud luxury surface valley tragic pair learn fun love regular tiger (address: g1PeKZ7kQ9S4z4BkDRxj4maCPupGnicoydA7U4ks75y5oMcBa)
- double anchor trouble broken bridge mammal feel twenty estate vast cabbage bracket (address: g1PwnRdmpfNiCoSAkzjvB1sJhuzssV54zA7f16nTP1UGqYJTN)
- eye light napkin panda vote issue energy riot awful cart save between (address: g1QJ65iy7DE66GcxW7bMP5d28Nicom22DXvC9dFh29ibp92Yo)
Elapsed: 38.0s | Keys generated: 303,204 | avg: 7978 keys/s | Time/match: 7.6s
If you build g1cli yourself, make sure you build in “release” mode and optionally with the proper rustflags for best performance when using this command.
Fixed
None
Deprecated
None
Removed
Two commands that were deprecated have been removed:
Yes je me suis fait avoir aujourd’hui je modifiais le code pour supporter les dérivations de clé avec passphrase en français et mes modifs ne semblaient rien faire ! Tu m’étonnes …
Du coup je vais peut-être déjà merger ce changement sur master (histoire d’éviter des soucis de merge plus tard avec tes changements ).
Pour la release “finale” il faudra encore adapter le g1_metadata.scale; changer la version dans cargo.toml vers 0.7.0 et refaire une release avec tag 0.7.0-g1 (doit terminer par “-g1” pour que le build homebrew fonctionne).
Je viens de mettre à jour le post original avec le build de release 0.7.0
Question pour les personnes sous MacOS; est-ce que quelqu’un pourrait vérifier si le Homebrew Formula qui a été déployé est bien correct (premier test depuis le changement de nom de package)
Pour le metadata.scale, tu devrais proposer une commande qui le met à jour en local. Comme un cache que l’on pourrait mettre à jour.
Ainsi si une erreur survient faute d’avoir un metadata non à jour, tu proposes à l’utilisateur de lancer la commande de mise à jour des metadatas. Lorsque tu fais cela, tu compare la version local avec la version en ligne (tags de version) et tu mets à jour si besoin. Sinon tu affiche un message précisant que les metadonnées sont à jour.
Il n’est pas souhaitable que le bon fonctionnement de g1cli dépende du fait que tu sois obligé de surveiller les mises à jour pour le faire à la main. Je dis ça pour ta tranquillité.
La lib Rust utilisée par g1cli, nommée « subxt », a besoin de connaître les métadonnées du runtime à la compilation afin de générer les types Rust correspondant à ceux définis dans les métadonnées du runtime. Cela permet de vérifier à la compilation, que le code manipule les données dans les bons formats.
Je ne connais pas bien les détails derrière cette génération des classes par subxt à partir du fichier de scale; aucune idée s’il y aurait moyen de permettre la mise à jour sans re-compilation…
Pas super clair non plus pour moi quelles opérations peuvent réellement êtres impactées par le runtime choisit (genre si on utilise g1cli compilé avec le runtime “gdev” mais pour “g1”; ou l’inverse)
Ça ne fonctionne pas comme ça. Pense les metadata comme un fichier de définition d’une API (par exemple un schéma graphql). Si on change le schéma, soit c’est non cassant et donc il n’y a pas besoin de mettre à jour, soit c’est cassant et donc de toute façon il faut bien écrire le code qui tient compte des changements et donc mettre à jour.
Pour être un peu plus concret, il contient par exemple la numérotation des pallets et la numérotation des calls. Par exemple pour renouveler une certification, c’est le call 3 de la pallet 43 (Duniter | Runtime calls). Je ne vois pas comment tu peux développer une application (y compris silkaj 2) sans l’utiliser.
C’était plus clair quand tous les runtimes n’étaient pas identiques. Par exemple, quand on ajoute ou supprime des calls, ça casse tout ! Il y a eu plusieurs exemples de mise à jour de runtime qui changeaient des choses comme celui là : update to runtime 800 (6f36165f) · Commits · clients / Rust / Ğ1cli · GitLab.
Tu as tout à fait raison sur le fait qu’il faut revoir son code si les métadonnées ont changé.
Mais quand on a le cul entre deux chaises, je fais en sorte que mon code s’adapte aux deux runtimes en cours (gdev/gtest, plus tard g1/gtest) en testant la présence/syntaxe des commandes selon la version. Tika, avec mon propre client substrate, détecte automatiquement si les metadata ont changé et stocke en locale toutes les versions qu’il détecte. Il peut alors basculer entre deux, et utiliser alors le bon fichier metadata pour chaque runtime, avec un code compatible pour les deux.
Cela fonctionne parfaitement. Je n’ai plus de dé-synchro entre mon client python et le nœud connecté en terme de metadata. Et ce, quelque soit la version de runtime auquel Tikka est connecté.
Les changements cassants ont été formateurs. Il faudra bien communiquer les prochains aux devs de clients pour anticiper.
@Moul le client python py-substrate-interface récupère une version de metadata par défaut sur le net, de mémoire (avec des risques d’incompatibilités pour Duniter). Sinon, tu peux lui fournir celui du runtime de Duniter, mais charge à toi de le récupérer du nœud pour lui fournir.
overrides what you may have already added in 
je modifiais le code pour supporter les dérivations de clé avec passphrase en français et mes modifs ne semblaient rien faire ! Tu m’étonnes …
(premier test depuis le changement de nom de package)