Résumé

  • PyPI présente le yank comme une alternative non destructive à la suppression.
  • PEP 592 rend le marqueur réversible et sépare ce signal du choix réellement fait par un installateur.
  • Une affirmation sérieuse exige des traces distinctes du dépôt, de la contrainte, de la résolution, de l’artefact et du déploiement.

Le mot « retirée » paraît définitif. La documentation PyPI est plus précise : un responsable peut retirer une version lorsque celle-ci est cassée, incompatible avec sa propre promesse, ou vulnérable. Ces motifs possibles ne sont pas inscrits comme un verdict dans le marqueur. Une raison facultative peut éclairer un utilisateur en aval; elle ne prouve ni incident, ni malveillance, ni décision valable pour toutes les installations.

L’action de gestion porte actuellement sur une version entière. PEP 592 décrit cependant l’attribut data-yanked sur les liens de l’API Simple, donc une représentation que les clients rencontrent au niveau des fichiers. Cette relation ne transforme pas l’état affiché en reçu de suppression, en décision sur l’autorité de publication, ou en preuve qu’un poste donné a reçu le fichier.

La sélection est un événement distinct. PEP 592 impose d’ignorer une version retirée lorsqu’une version non retirée satisfait la contrainte, tout en laissant au client la possibilité de la refuser même sans solution satisfaisante. Le comportement documenté de PyPI pour une version exacte est lui aussi borné. Pour décrire un résultat, il faut conserver la contrainte, le verrou éventuel, l’index observé, la version de l’outil, son moment et ses avertissements. Le drapeau actuel ne reconstitue pas une résolution passée.

La suppression est encore une autre surface. PyPI précise qu’un yank ne libère pas d’espace, tandis qu’une suppression est permanente sans intervention administrative et peut briser des dépendances verrouillées. « Toujours présent » n’équivaut donc pas à « approuvé », et « retiré » n’équivaut pas à « disparu partout ». Les champs JSON yanked et yanked_reason décrivent la présentation du dépôt, non un téléchargement, une exécution ou un jugement de sécurité.

Daniel Kade propose un reçu en cinq liens : observation datée du dépôt; contrainte ou verrou exact; décision du résolveur et hash obtenu; éléments séparés sur suppression, autorité ou vulnérabilité; puis inventaire ou preuve de déploiement. Les identifiants sensibles peuvent rester protégés; la jonction ne doit pas être supposée.

Sources

  1. PyPI Docs — Yanking
  2. PEP 592
  3. PyPI Docs — Storage Limits
  4. PyPI Docs — JSON API