Draft: (paused) Use workspace for Cargo.toml files

Cargo provides a workspace feature (book, reference). We can use it to avoid repetition.

added 8 commits

• d115738c...1d2bb1b9 - 2 commits from branch master
• 35174549 - toml extension recomendation
• 4c4bb437 - workspaced the repo
• f06aec84 - workspaced node dependencies
• eae255d1 - runtimes using workspace deps
• eef3531f - live tests using workspace dependencies
• 9002ff05 - a lot of toml cleanup -- not sure about all the versions

Compare with previous version

(simply rebased on master because of added readme files)

added 1 commit

• dd879b33 - keep descriptions

Compare with previous version

added RN-binary label

marked this merge request as ready

I successfully build Duniter with default options (gdev runtime) and ran all the tests (cargo test --workspace --exclude duniter-live-tests). Everything seems to be well defined as root Cargo.toml members.

requested review from @tuxmain

added RN-runtime label

removed RN-runtime label

Because there are different features, notably std. Runtime crates are no-std.

I did not see this comment. Maybe @jrx you want to continue this MR?

Ho sorry, I didn't see the comment. So indeed, I made me feel weird the crate imported with different names in multiple places. Has a rule of thumb, I avoid tweaked dependency names, it causes more indirection for "reasons?". I didn't want to enforce this rule right away, and @tuxmain seems to know the "why".

On this MR I tried to just factorise version in the workspace toml but avoid doing any other big change. Big changes could come after (or never).

@HugoTrentesaux If you like it like that, it's good IMO.

@HugoTrentesaux I think we can switch to codec everywhere and just specify the additional features where needed.

Polkadot uses this package under a mix of codec and parity_scale_codec aliases. We could homogenise but I don't feel like it's worth it.

To answer the question:

WHY TWICE THE SAME PACKAGE WITH DIFFERENT NAMES ?

Because @jrx added parity-scale-codec in commit eef3531f. Before that, it was only present under the name codec.

Je suis sceptique sur ces définitions globales. documentation ne sert pas pour l'instant, s'il y est il faudrait que ça pointe vers la documentation de la crate. Je pense que description aussi concerne la crate. Quant à authors ce n'est pas une question légale (l'avis de copyright est dans le README et dans chaque fichier), donc je pense qu'il vaut mieux voir l'aspect pratique : il peut servir à contacter les auteurs. Donc j'y mettrais plutôt les auteurs principaux des crates, les personnes à contacter si on a besoin d'aide sur telle crate. Comme ça les infos sur une crate sont dans la crate elle-même.

Là dessus, j'ai bouriné par contre (mea culpa). J'aime bien l'idée qu'on ait un "par défaut" commun, et quitte à modifier chaque crate qui le mérite en conséquence. Pour la notion d'auteur d'une crate, ça me semble pas nécessaire de le documenter, il y'a quelques clics seulement de la documentation d'une crate rust au repo avec git history de son code source, donc ça me semble assez simple et détaillé de remonté à l'auteur par se moyen. Donc as you wish, c'est juste une proposition.

Je suis d'accord, si ces champs sont optionnels, on peut tout simplement les retirer

• documentation : sera probablement dans le README de chaque pallet
• description : j'ai conservé une description par crate dans le dernier commit, mais pas modifié le workspace, il faut retirer tu penses ?
• authors : oui, c'est une question pratique plus que légale, on peut s'en passer tout court je pense et mettre tous les contributeurs à l'échelle du projet. Pour savoir à qui s'adresser, il y a plus simple que de définir ça dans les cargo.toml

(ah bah @jrx a été plus rapide que moi pour répondre, j'étais en train de rédiger ><) Donc on est d'accord. Est-ce que tu veux bien continuer ou on doit prendre le relais ?

Les champs documentation, description et authors sont surtout utiles si on veut publier les crates sur crates.io (ce qui pourra arriver pour certaines, que ce soit pour faciliter le développement de l'écosystème Duniter Rust, ou pour Substrate globalement).

marked this merge request as draft

changed title from Draft: Use workspace for Cargo.toml files to Draft: (paused) Use workspace for Cargo.toml files

mentioned in issue #170 (closed)

Ça va peut-être se faire dans !236 (merged)

Je ferme vu que !236 (merged) règle ça.

closed