Cargo: Faire du « cargo obsolète » une partie de la cargaison elle-même

Je suis sûr qu'il existe de nombreux exemples où ceux-ci peuvent être utiles. En voici une qui m'a inspiré pour rédiger cette proposition : https://github.com/servo/unicode-bidi/issues/46#issuecomment -316778436

/cc @alexcrichton , @Manishearth , @anowell

Je pense que nous voudrions probablement décrire ce que font les autres gestionnaires de paquets ici, par exemple, npm, fil, bundler, rubygems, pip, etc. font-ils quelque chose comme ça? J'avais personnellement l'impression que ce genre de préoccupations était généralement confié à un service tiers.

Voici un résumé des fonctionnalités similaires de certains autres gestionnaires de packages.

JS NPM

NPM CLI a une sous-commande outdated intégrée qui affiche l'état des packages auxquels leurs versions actuelles , souhaitées et les plus récentes ne correspondent pas.

Comme cargo update , le npm update jour la version actuelle en want , si nécessaire et possible.

Il semble que npm update n'ait plus de fonctionnalités dans ce domaine. De plus, aucune autre sous-commande ne semble liée.

Réf : https://docs.npmjs.com/cli/outdated

La description

(de https://github.com/npm/npm/blob/latest/doc/cli/npm-outdated.md )

Cette commande vérifiera le registre pour voir si des packages installés (ou spécifiques) sont actuellement obsolètes.

En sortie :

• wanted est la version maximale du package qui satisfait la plage semver spécifiée dans package.json . S'il n'y a pas de plage de serveurs disponible (c'est-à-dire que vous utilisez npm outdated --global , ou que le package n'est pas inclus dans package.json ), alors wanted affiche la version actuellement installée.

• latest est la version du package la plus récente dans le registre. L'exécution de npm publish sans configuration spéciale publiera le package avec une balise dist de latest . Cela peut ou non être la version maximale du package, ou la version la plus récemment publiée du package, selon la façon dont le développeur du package gère le dernier dist-tag(1).

• location est l'endroit où se trouve le package dans l'arborescence des dépendances. Notez que npm outdated défaut une profondeur de 0, donc à moins que vous ne l'ignoriez, vous ne verrez toujours que les dépendances de niveau supérieur qui sont obsolètes.

• package type (lors de l'utilisation de --long / -l ) vous indique si ce package est un dependency ou un devDependency . Les forfaits non inclus dans package.json sont toujours marqués dependencies .

Exemple

Modifiez package.json et ajoutez "underscore": "1.7" à la liste des dépendances.

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore  MISSING   1.7.0   1.8.3  underscore

$ npm install
[email protected] node_modules/underscore

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore    1.7.0   1.7.0   1.8.3  underscore

Fil JS

Yarn CLI a une sous-commande outdated intégrée pour "vérifier les dépendances de package obsolètes".

Réf : https://yarnpkg.com/lang/en/docs/cli/outdated/

La description

Répertorie les informations de version pour toutes les dépendances de package. Ces informations incluent la version actuellement installée, la version souhaitée basée sur semver et la dernière version disponible.

Par exemple, supposons que votre package.json a les dépendances suivantes répertoriées :

"dependencies": {
  "lodash": "4.15.0",
  "underscore": "~1.6.0"
}

La commande exécutée devrait ressembler à ceci :

yarn outdated
Package    Current Wanted Latest
lodash     4.15.0  4.15.0 4.16.4
underscore 1.6.0   1.6.0  1.8.3 
✨  Done in 0.72s.

Gemmes de rubis

Gems CLI a une sous-commande outdated intégrée pour « afficher toutes les gemmes qui nécessitent des mises à jour ».

Réf : http://guides.rubygems.org/command-reference/#gem-outdated

La description

(À partir de la réf.)

La commande obsolète répertorie les gemmes que vous souhaiterez peut-être mettre à niveau vers une version plus récente.

Vous pouvez vérifier les incompatibilités de dépendance à l'aide de la commande de dépendance et mettre à jour les gems avec les commandes de mise à jour ou d'installation.

Lot de rubis

Bundler CLI a une sous-commande outdated intégrée pour « lister les gems installées avec des versions plus récentes disponibles ».

Réf : https://bundler.io/v1.11/bundle_outdated.html

La description

(À partir de la réf.)

Obsolète répertorie les noms et les versions des gems qui ont une version plus récente disponible dans la source donnée. L'appel obsolète avec [GEM [GEM]] ne vérifiera que les versions les plus récentes des gemmes données. Par défaut, les gemmes d'avant-première disponibles seront ignorées.

Python PIP

La sous-commande list PIP CLI a une option --outdated , pour "lister les packages obsolètes", et une option --uptodate pour "lister les packages à jour".

Réf : https://pip.pypa.io/en/stable/reference/pip_list/

Exemples

Liste des packages installés.

$ pip list
docutils (0.10)
Jinja2 (2.7.2)
MarkupSafe (0.18)
Pygments (1.6)
Sphinx (1.2.1)

Répertoriez les packages obsolètes (hors modifiables) et la dernière version disponible.

```
Liste de pip $ --obsolète
docutils (Actuel : 0,10 Dernier : 0,11)
Sphinx (Actuel : 1.2.1 Dernier : 1.2.2)

En résumé:

1. Les gestionnaires de packages JS et Ruby ont une sous-commande outdated intégrée pour répertorier les packages "pas en règle", ce qui signifie que leur version installée n'est pas ce qui est demandé, ou ce qui est demandé n'est pas la dernière version en amont ( pas nécessairement la plus grande, mais la dernière version stable).

2. Python PIP a des fonctionnalités similaires via la sous-commande intégrée list , ce qui le rend plus générique, mais plus difficile à découvrir et à utiliser pour les utilisateurs débutants/moyens.

3. On dirait que toutes ces commandes sont en lecture seule et n'ont aucune fonctionnalité intégrée pour mettre à jour les fichiers manifestes vers la dernière version.

4. Je n'ai vu aucun signe de fonctionnalité de type avertissement concernant les packages obsolètes dans d'autres commandes.

Ainsi, à mon humble avis, nous pouvons planifier ces fonctionnalités, applicables uniquement aux dépendances directes d'un package/espace de travail.

a) Une commande outdated intégrée pour aider les développeurs à trouver les dépendances directes obsolètes. Ce serait la lecture seule et la sortie lisible par l'homme sera similaire aux gestionnaires de packages JS/Ruby.

b) Développez (a) pour prendre en charge les espaces de travail.

c) Ajoutez des options à outdated pour le rendre en lecture-écriture, en mettant à jour les numéros de version d'une/plusieurs/toutes les dépendances obsolètes. Ceci, je suppose, serait la seule/première commande de fret à écrire dans le manifeste, ce qui nécessiterait donc plus de travail de conception et de mise en œuvre.

d) Développez (c) pour prendre également en charge les espaces de travail.

Ces deux éléments peuvent suffire aux scripts shell et aux commandes de fret tierces pour créer facilement des automatisations pour des mises à niveau stables, ce qui signifie qu'ils exécutent les tests avec des mises à niveau uniques et reviennent s'il y a des erreurs de compilation ou de test.

Qu'en penses-tu?

https://crates.io/crates/cargo-outdated fonctionne bien aujourd'hui

Malheureusement, le package cargo-outdated ne prend pas encore en charge les espaces de travail.

En outre, une question porterait sur la proposition initiale d'ajouter un avertissement cargo update sur l'existence de packages obsolètes. J'aimerais savoir ce que tout le monde pense de ça.

Je serais totalement réticent à ajouter outdated support natif de cargo-outdated pour assurer notre coordination. Je sais que je l'utilise assez souvent !

Merci beaucoup d'avoir fait cette enquête @behnam , c'est très utile !

Un gros +1 pour avoir cargo outdated intégré.

J'utilise cargo-outdated depuis des lustres maintenant, mais comme le dit @behnam , il ne prend pas encore en charge les espaces de travail et j'en utilise tellement avec yarn et pip que je le crois devrait faire partie de Cargo.

Juste pour mettre à jour la sortie du fil, cela ressemble en fait à ce qui suit maintenant :

Package            Current       Wanted  Latest  Package Type    URL                                                       
@types/lodash      4.14.70       4.14.71 4.14.71 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
@types/react       15.0.38       15.0.39 15.0.39 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
gulp               4.0.0-alpha.2 exotic  exotic  devDependencies gulpjs/gulp#4.0                                           
signature_pad      2.2.0         2.2.1   2.2.1   dependencies    https://github.com/szimek/signature_pad                   
webpack-dev-server 2.5.1         2.6.1   2.6.1   devDependencies http://github.com/webpack/webpack-dev-server              
Done in 2.27s.

Avoir l'URL dans la sortie est assez agréable pour pouvoir aussi voir les changements. Séparer les dépendances de développement, les dépendances de construction et les dépendances plus proprement que le fil serait également bien, mais cela pourrait alors devenir trop complexe à afficher avec les espaces de travail.

Un changement à faire par rapport à cargo-outdated qui est déjà mentionné est que imo, il ne devrait répertorier que les dépendances directes du projet, pas les sous-dépendances. Voici un exemple sur un de mes projets :

    Name             Project Ver  SemVer Compat  Latest Ver
    hyper               0.10.12        --          0.11.1
    hyper->base64       0.5.2          --          0.6.0
    hyper->mime         0.2.6          --          0.3.2
    hyper->unicase      1.4.2          --          2.0.0
    slug->unidecode     0.2.0          --          0.3.0

Je ne me soucie que de hyper dans cette liste.

Si nous voulons aller c), je recommanderais de vérifier la commande yarn upgrade-interactive comme exemple de la façon de la gérer.

Je serais intéressé de faire la mise en œuvre si cela finit par être accepté pour le fret !

Bonnes idées, @Keats !

Avoir l'URL dans la sortie est assez agréable pour pouvoir aussi voir les changements.

D'accord.

De plus, sur une note similaire, une option --verbose qui vous montre également tous en règle, vous indiquant ce qui a été dans la liste de contrôle.

Séparer les dépendances de développement, les dépendances de construction et les dépendances plus proprement que le fil serait également bien

Je ne sais pas ce que build-dependencies est ici. Mais, à propos de dev-dependencies , ils ont convenu que parfois ce n'est pas un problème et qu'il vaut mieux pouvoir le laisser en dehors du calcul. Donc, peut-être avons-nous besoin d'un ensemble d'options pour désactiver chaque groupe de ces dépendances.

mais il peut alors devenir trop complexe à afficher avec des espaces de travail.

En fait, je pense que la fonctionnalité de lecture seule ne sera pas si complexe pour les espaces de travail, car il devrait déjà y en avoir un Cargo.lock .

Mais c'est un bon rappel que nous avons également besoin de quelque chose comme location NPM, qui montre quel package local (dans l'espace de travail) dépend de l'ancienne version.

Et en plus, ce serait l'outil interne de Cargo pour alerter sur un espace de travail (ou même un package) ayant des dépendances

il ne doit répertorier que les dépendances directes du projet, pas les sous-dépendances.

Exactement. Je ne sais pas si nous voulons qu'une fonctionnalité effectue ces vérifications à plus d'un niveau de profondeur. Je pense que nous pouvons commencer par les services

Je serais intéressé de faire la mise en œuvre si cela finit par être accepté pour le fret !

Impressionnant! Je ne pourrai pas y arriver dans les prochaines semaines, mais je peux aider avec quelques tests et critiques, si nécessaire.

Il semble donc que nous ayons un consensus général sur les fonctionnalités de base d'une sous-commande outdated intégrée et le reste peut être discuté par PR, je suppose.

Aussi, écrivons en CC cargo-outdated . @kbknapp , qu'en pensez-vous ?

Je ne sais pas quelles sont les dépendances de construction ici. Mais, à propos des dépendances de développement, j'ai convenu que parfois ce n'est pas un problème et qu'il vaut mieux pouvoir le laisser en dehors du calcul. Donc, peut-être avons-nous besoin d'un ensemble d'options pour désactiver chaque groupe de ces dépendances.

Les dépendances de construction seraient bindgen par exemple : https://github.com/compass-rs/sass-rs/blob/master/sass-sys/Cargo.toml#L16
Il est important d'afficher les dépendances de développement dans JS-land car j'ai plus de dépendances de développement que de dépendances réelles, mais je pense qu'il est toujours logique d'afficher des informations obsolètes pour toutes les caisses répertoriées dans mon Cargo.toml par défaut. Nous pourrions avoir un indicateur pour désactiver les dépendances build/dev mais je ne pense pas qu'il serait utilisé très souvent : si vous exécutez cargo outdated , vous voulez généralement voir toutes les caisses.

En fait, je pense que la fonctionnalité de lecture seule ne sera pas si complexe pour les espaces de travail, car il devrait déjà y avoir un Cargo.lock.

Mon souci était plutôt de savoir comment bien l'afficher dans le terminal lorsque vous avez de nombreux espaces de travail comme habitat . Je suppose que faire défiler un peu n'est pas un gros problème

D'accord, @Keats. :)

Chose amusante à propos de build-dependencies : je pourrais dire ce que c'est, mais je ne l'ai trouvé nulle part sous la référence manifeste : http://doc.crates.io/manifest.html . Il s'avère que cela n'est mentionné que dans cette autre page : http://doc.crates.io/specifying-dependencies.html#build-dependencies Je vais soumettre un PR pour l'ajouter à la liste dans http://doc.crates .io/manifest.html#dependency-sections pour que cela ne se reproduise plus.

@alexcrichton , est-ce quelque chose qui nécessite une RFC, ou pouvons-nous aller de l'avant avec le consensus général ici et commencer la mise en œuvre ?

S'il n'y a pas de RFC, je suppose que nous pouvons créer un nouveau problème de suivi pour la sous-commande intégrée cargo outdated avec les détails, et laisser ce problème pour la discussion d'autres questions connexes, comme l'avertissement proposé sur cargo update lorsqu'il reste des colis.

Désolé à tous, je viens de voir ça ! Je suis tout à fait d' cargo outdated avec l'ajout d'une commande native @Frederick888 s'est mobilisé pour aider spécifiquement avec cargo-outdated .

La plus grande chose que je vois qui doit se produire pour cargo-outdated (natif ou tiers) est d'ajouter la prise en charge de l'espace de travail.

@Keats

Je ne me soucie que de hyper dans cette liste.

cargo-outdated (sous-commande tierce) a actuellement les options -R, --root-deps-only ou --depth=# qui font exactement ce que vous recherchez.

Il y a aussi -r, --root=PKG pour traiter un paquet particulier comme racine, et enfin -p, --package=PKG pour rechercher uniquement les mises à jour pour un paquet/crate particulier. Tout cela devrait également être combinable.

Légèrement hors sujet, ce genre d'aborde le sujet des sous-commandes tierces se rapprochant des commandes natives, et s'il existe une méthode ou un endroit officiel pour que cela se produise ? De la même manière que les bibliothèques se déplacent vers la pépinière, existe-t-il un endroit où les sous-commandes tierces peuvent se rapprocher de cargo lui-même, peut-être même distribuées par défaut ? Il y a des moments où cela peut être moins de travail que de ré-implémenter des fonctionnalités. Je comprends qu'avec outdated il peut être plus facile de dupliquer simplement la fonctionnalité à l'intérieur de cargo , mais je doute fortement que ce soit la dernière fois que ce genre de situation se produira. Juste penser à voix haute. :clin d'œil:

Je ne me soucie que de l'hyper dans cette liste.

cargo-outdated (sous-commande tierce) a actuellement les options -R, --root-deps-only ou --depth=# qui font exactement ce que vous recherchez.

Il y a deux raisons pour lesquelles vous pourriez avoir une dépendance obsolète d'une caisse que vous utilisez. Soit l'auteur n'a pas encore mis à jour, soit vous avez l'ancienne version dans votre fichier Cargo.lock . cargo-outdated colonne SemVer Compat devrait probablement aider ici, mais je n'ai jamais pu comprendre comment cela fonctionne, par exemple :

    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --

Alors de temps en temps je retire mes Cargo.lock pour en obtenir un nouveau.

@lnicola

Je ne pourrais jamais comprendre comment ça marche

Nous venons de faire une nouvelle version. Pourriez-vous s'il vous plaît le tester à nouveau?

@kbknapp

Légèrement hors sujet, ce genre d'aborde le sujet des sous-commandes tierces se rapprochant des commandes natives, et s'il existe une méthode ou un endroit officiel pour que cela se produise ?

Bon point. En fait, lorsque j'étais en train cargo-outdated refactoriser cargo tant que dépendance car cela avait tendance à être un peu exagéré (et me coûterait beaucoup de temps pour lire les documents) . Mais maintenant, si nous parlons d'intégrer la fonctionnalité dans cargo lui-même, ce dont je suis également satisfait, apparemment, dépendre de cargo est un meilleur choix.

Alors oui, il serait préférable d'avoir une telle directive, ou même une liste de suggestions de développement de sous-commandes pour les développeurs.

Je cherchais littéralement une nouvelle version quand vous avez écrit ça 😀.

Avant de:

    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --
    r2d2-diesel->diesel      0.15.1       0.15.2        0.15.2
    rocket->hyper            0.10.12        --          0.11.2
    time->libc               0.2.28       0.2.29        0.2.29
    uuid->rand               0.3.15       0.3.16        0.3.16
    time->redox_syscall      0.1.27       0.1.29        0.1.29
    toml->serde              1.0.10       1.0.11        1.0.11
    rocket->smallvec         0.4.1          --          0.2.1
    rocket_contrib->tera     0.10.8       0.10.9        0.10.9
    rocket->toml             0.4.2        0.4.4         0.4.4

Après:

Name                         Project Ver  SemVer Compat  Latest Ver
backtrace->libc                 0.2.28       0.2.29        0.2.29
backtrace-sys->libc             0.2.28       0.2.29        0.2.29
diesel                          0.15.1       0.15.2        0.15.2
diesel_codegen->diesel          0.15.1       0.15.2        0.15.2
diesel_infer_schema->diesel     0.15.1       0.15.2        0.15.2
isatty->libc                    0.2.28       0.2.29        0.2.29
memchr->libc                    0.2.28       0.2.29        0.2.29
num_cpus->libc                  0.2.28       0.2.29        0.2.29
r2d2-diesel->diesel             0.15.1       0.15.2        0.15.2
rand->libc                      0.2.28       0.2.29        0.2.29
rayon-core->libc                0.2.28       0.2.29        0.2.29
rayon-core->rand                0.3.15       0.3.16        0.3.16
ring->libc                      0.2.28       0.2.29        0.2.29
rocket->toml                    0.4.2        0.4.4         0.4.4
rocket_contrib->serde           1.0.10       1.0.11        1.0.11
rocket_contrib->tera            0.10.8       0.10.9        0.10.9
serde                           1.0.10       1.0.11        1.0.11
serde_json->serde               1.0.10       1.0.11        1.0.11
tera->serde                     1.0.10       1.0.11        1.0.11
time->libc                      0.2.28       0.2.29        0.2.29
time->redox_syscall             0.1.27       0.1.29        0.1.29
toml->serde                     1.0.10       1.0.11        1.0.11
uuid->rand                      0.3.15       0.3.16        0.3.16

Après avoir supprimé Cargo.lock :

All dependencies are up to date, yay!

??

Après avoir retiré Cargo.lock :

@lnicola , êtes-vous en train de dire que cargo update ne vous donne pas les mêmes résultats ? Si oui, pouvez-vous être un peu plus précis sur les circonstances dans lesquelles cela se produit ?

@behnam J'en avais en fait une copie, alors je viens d'essayer cargo update dessus. On dirait que les résultats étaient les mêmes ("Toutes les dépendances sont à jour").

Si vous demandez pourquoi j'ai dit que je supprime Cargo.lock au lieu d'exécuter cargo update , il n'y a pas de raison particulière.

@Frederick888 En regardant ma sortie, je pense que les mises à jour de dernière minute pour les dépendances ne sont plus signalées?

    rocket->hyper            0.10.12        --          0.11.2

@lnicola En fait, cela n'était pas censé être signalé. Auparavant, si un package avait plusieurs occurrences avec des exigences de versions/semver différentes dans l'arborescence des dépendances, le programme pouvait parfois mal se comporter.

cargo-outdated vérifie la "dernière" version en remplaçant les exigences semver des dépendances directes par "*" , ce qui signifie qu'il ne vous donne pas vraiment les "dernières versions" des versions indirectes . Ce n'est parfois pas tout à fait intuitif et il y a un problème connexe pour cela (kbknapp/cargo-outdated#25).

Auparavant, si un package avait plusieurs occurrences avec des exigences de versions/semver différentes dans l'arborescence des dépendances, le programme pouvait parfois mal se comporter.

Je ne pense pas que ce soit le cas pour hyper dans mon exemple.

vérifie la "dernière" version en remplaçant les exigences semver des dépendances directes par "*", ce qui signifie qu'il ne vous donne pas vraiment les "dernières versions" des versions indirectes.

Je vois. Il peut être utile de les signaler, afin que vous sachiez que vos dépendances utilisent des caisses plus anciennes. Mais je ne me sens pas trop fort à ce sujet.

En ce qui concerne l'utilisation plus facile pour les bibliothèques tierces des internes cargo et l'intégration de commandes tierces intégrées : peut-être diviser la cargaison en caisses plus petites (dans un référentiel, configuré comme espace de travail ) aiderait?

Fondamentalement, je pense que la lecture et la validation du manifeste (avec une compréhension de l'espace de travail et de diverses dépendances) devraient être une bibliothèque distincte des commandes consommant le manifeste pour prendre des mesures.

Il y a beaucoup de discussions dans ce numéro sur de nombreux sujets - les internes pourraient être un meilleur endroit pour ces discussions.

Après avoir lu, il semble que le problème le plus ciblé ici soit de déplacer cargo outdated dans l'arborescence pour devenir une commande officiellement prise en charge, j'ai donc changé le titre du problème pour refléter cela.

Je pense qu'une partie de la confusion à propos de "pourquoi cargo-outdated ne me montre-t-elle pas X " provient également de https://github.com/kbknapp/cargo-outdated/issues/134 , que j'ai vient de tomber sur.

Y a-t-il des progrès actuels à ce sujet? Est-ce que n'importe qui sait quel était le dernier statut de ceci en amont ?

Avons-nous une mise à jour pour cela? J'aime cargo-outdated bien que je pense qu'il devrait y avoir une sous-commande standardisée à l'intérieur de la cargaison qui vérifie les colis obsolètes. Comme les nouveaux utilisateurs auraient besoin de rechercher un package juste pour exécuter certaines fonctionnalités

Juste en laissant une note ici que l'arbre de cargaison a récemment été adopté dans la cargaison proprement dite dans https://github.com/rust-lang/cargo/pull/8062 , ce qui, du moins pour moi, indique qu'il n'est pas impossible que la même chose puisse arriver à cargaison périmée si quelqu'un fait le travail.

cc @deg4uss3r

Merci pour le cc @kbknapp Je suis en train de

Hé, avez-vous pu examiner cette possibilité ?

@svenstaro Oui j'ai ! Les progrès avancent lentement, mais j'y travaille :) commencer le nouveau travail en même temps est difficile cependant

Ok chéri, merci pour la mise à jour !

@deg4uss3r ping amical :D

@svenstaro Merci beaucoup de me garder honnête !

Donc, je travaille là-dessus; cependant, je l'ai fait hors ligne parce que je vois beaucoup de petites choses à améliorer sur cargo-oudated que j'aimerais simplifier en tant que sous-commande de fret, tout en conservant éventuellement cargo-outdated tant que option basée sur un projet plus lourd. Voici donc mon travail à l'air libre : https://github.com/deg4uss3r/outdated2

Cela va avoir l'air TRÈS rude en ce moment, je suis désolé, ça a été une année 2020 assez intéressante jusqu'à présent !

Cela simplifie donc le projet en ne regardant que les dépendances de l'espace de travail et en demandant les dernières informations à https://crates.io via l'API. Je pense que c'est le meilleur choix à ajouter à la cargaison car nous voulons qu'il fonctionne toujours, plus de problèmes de compilation avec des dépendances conflictuelles et il ne vérifiera que les dépendances obsolètes du projet en cours plutôt que de plonger dans des dépendances sur lesquelles le lanceur n'aura aucun contrôle. .

Il y a BEAUCOUP (comme vous pouvez le constater) sur lequel je dois travailler, le plus important est l'intégration avec cargo directement, mais j'ai prêté une attention particulière aux dépendances que cargo utilise pour m'assurer que je Je réutilise ce qui est déjà importé. Jusqu'à présent, je vois que j'ai besoin de vraiment étoffer avant de réellement charger le MR :

• [ ] Ne signalez que les mises à jour sur le canal dans lequel se trouve la dépendance (par exemple, ne proposez pas de version bêta lorsque l'utilisateur utilise une version stable)
• [ ] Gestion correcte des erreurs
• [ ] Intégration de la ligne de commande pour les options
• [ ] prise en charge de la sortie json

J'aimerais avoir des opinions sur cette version réduite avant de continuer plus loin car, personnellement, je pense que c'est ce que nous voulons en tant que sous-commande cargo , mais je pourrais être totalement minoritaire là-bas.

Edit: je suis sûr qu'il y a des optimisations très simples que je n'ai pas encore faites mais pour le moment c'est assez rapide, cela prend environ 9 secondes (version de build, de rustc stable 1.46 ) pour le servo... qui est pas mal pour quelque chose comme ça !

Super de voir des progrès !

Depuis que vous avez demandé des commentaires : Fonctionnalités que j'aime beaucoup dans la version actuelle : --ignore , --depth , --workspace . --exit-code est intéressant pour CI.

J'utilise assez souvent cargo outdated -R/--root-deps-only , car la sortie standard est un peu verbeuse.

Je suggère de regarder yarn upgrade-interactive --latest pour une interface de mise à niveau vraiment propre. J'utilise souvent des cargaisons obsolètes, mais devoir changer chaque département manuellement est pénible.