error: uncommitted changes detected, please resolve before release:
.idea/ (WT_NEW)
Upgrading duniter-core from 1.8.1 to 1.8.2
Publishing duniter-core
Updating crates.io index
error: all dependencies must have a version specified when publishing.
dependency `dubp-wot` does not specify a version
Note: The published dependency will use the version from crates.io,
the `path` specification will be removed from the dependency declaration.
Ça ne sert à rien de publier ça sur crates.io, pas besoin de s’embêter avec ça.
Il faudra demander à Élois qu’il nous passe les droits, pour virer les crates obsolètes et éventuellement publier celles pour lesquelles c’est pertinent.
La dépendance est indiquée par adresse du dépôt git alors il affiche la version qu’il trouve dans le Cargo.toml de la dépendance. Il ne passe pas par crates.io pour ces dépendances.
L’erreur doit venir de la présence de méthodes dans l’implémentation de DuniterModule qui ne sont pas dans la définition du trait. Si tu as ajouté ces méthodes dans un autre dépôt, il faut soit merger ce dépôt d’abord, soit ajouter des lignes patch dans le Cargo.toml pour changer temporairement l’adresse de la dépendance (on peut préciser la branche). Specifying Dependencies - The Cargo Book
la version 1.8.1, qui n’est pourtant pas préciser dans le Cargo.toml. En revanche, je trouve quelque chose dans le fichier lock. Faut il le mettre à jour ? Comment ?
le hash du commit correspond à un vieux commit, qui n’a pas mes nouvelles méthodes
tout le reste (les erreurs) semble la conséquence de ce problème de checkout. Il faut le résoudre en premier lieu, sauf erreur.
Cargo.lock conserve les versions des dépendances y compris transitives, ce qui permet de garder les mêmes versions des dépendances même si elles ne sont pas marquées dans Cargo.toml. Il n’est pas censé être édité à la main.
En effet j’avais oublié qu’il peut être nécessaire de faire cargo update pour le mettre à jour, sinon il va garder un vieux commit de duniter-core.
J’ai fait un cargo update du projet duniter-gva et pushé le Cargo.lock sur ma MR. Mais la pipeline est toujours en erreur : maintenant, la compilation ne trouve plus certaines dépendances (auxquelles je n’ai pas touchées !).
Je dois mal m’y prendre, également je vois que mon fichier lock à changé de format…
Je suis peut-etre sur une version trop récente de Rust ?
$ cargo version
cargo 1.70.0 (ec8a8a0ca 2023-04-25)
@tuxmain as tu moyen de tester de ton côté, et si besoin corriger ma MR ou me dire ce qui cloche ?
Chez moi (1.72.0) la version de async-bincode ne pose pas de problème mais il y a une erreur de compilation après. Je ne sais pas pourquoi ça ne marche pas dans le pipeline.
En effet on pourrait essayer de passer à la release d’aujourd’hui. On gagnerait aussi en performance de compilation et d’exécution et en compatibilité. Ce doit être défini dans un fichier relatif à docker et/ou gitlab, mais si on n’a pas de chance il faut changer une image docker autre part et là je ne sais pas faire…
J’ai poussé un correctif. Par contre, prenez le temps de comprendre comment fonctionne ce dépôt. Ça uploade l’image sur Docker Hub lorsqu’il y a un tag.
Par contre, je ne suis pas sûr si le bump de version, corresponds à la version de Rust.
