(message qui n’intéressera que les gens qui s’intéressent à la structure du code de Duniter v2)
J’étais parti pour supprimer la feature distance-oracle/std qui est obligatoire, mais j’ai vu qu’il y a aussi node/std, dc-distance/std (aussi obligatoires). (et il y a aussi node/standalone je ne sais pas pourquoi)
Je m’interroge aussi sur l’utilité de dc-distance/runtime-benchmarks.
Est-ce volontaire de garder les mêmes features dans toutes les crates pour l’uniformité, même si elles sont fondamentalement inutiles (soit impossibles, soit obligatoires), ou bien je peux les supprimer ?
Je ne parle pas de features pas encore utilisées parce que “todo”, celles-là oui il faut les garder.
Les features inutiles font qu’on se demande ce que ferait le code avec/sans elles, ce qui n’a pas de sens (du code client sans std ne compilera pas).
1 Like
Les features /std permettent de voir là où on utilise la std. Effectivement comme on ne prévoit pas de rendre certaines parties accessibles en no-std elles n’ont pas plus de sens que ça. Leur utilité peut être d’aider de traquer les dépendances std.
Pour standalone, ça vient de toi, mais n’étant pas utilisée, on peut la supprimer entièrement en effet.
Pour dc-distance/runtime-benchmarks, ça n’a pas tellement de sens, je n’aurais pas dû laisser passer ça. À retirer en effet.
Plus que pour l’uniformité, je dirais que c’est pour s’éviter de réfléchir. De toute façon le découpage en crate est parfois assez arbitraire puisque peu de crates sont susceptibles d’être utilisées dans un autre contexte. Il n’y a évidemment pas de problème à supprimer les features inutiles, si je ne l’ai pas fait c’est clairement par flemme de les passer au peigne.
La feature qui serait intéressante à remettre en place, c’est try-runtime, mais je trouve ça trop compliqué, j’ai pas pris le temps de me plonger dedans.
distance-oracle/standalone c’est uniquement pour utiliser l’oracle seul, ça n’a pas de sens s’il est utilisé en dépendance. (mon objectif n’était pas de dire de qui ça vient mais non node/standalone ne vient pas de moi)
Pour l’instant je change un minimum de choses, juste pour régler le problème du cron+oracle. Je ne touche pas aux std et tout.
Je trouverais plus clair que :
- Une feature std signifie que la crate peut fonctionner avec ou sans.
- Une crate sans feature std dépendrait obligatoirement de std.
- Une crate sans feature std mais avec le keyword
no-std (convention reconnue par crates .io même si ce n’est pas important ici) n’aurait jamais besoin de std.
Certes les palettes n’ont pas besoin du découpage en crates, mais on utilise vraiment plusieurs ensembles différents de features pour les crates du dossier primitives, qui sont utilisées à la fois en client (std) et en runtime (no-std).