Demande de packages Python depuis des connexions en amont et externes - CodeArtifact

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Demande de packages Python depuis des connexions en amont et externes

Lorsque vous importez une version de package Python depuis pypi.org, tous les actifs de cette version de package CodeArtifact seront importés. Alors que la plupart des packages Python contiennent un petit nombre d'actifs, certains en contiennent plus de 100, généralement pour prendre en charge plusieurs architectures matérielles et interpréteurs Python.

Il est courant que de nouveaux actifs soient publiés sur pypi.org pour une version de package existante. Par exemple, certains projets publient de nouvelles ressources lorsque de nouvelles versions de Python sont publiées. Lorsqu'un package Python est installé à partir de CodeArtifact withpip install, les versions du package conservées dans le CodeArtifact référentiel sont mises à jour pour refléter le dernier ensemble d'actifs de pypi.org.

De même, si de nouveaux actifs sont disponibles pour une version de package dans un CodeArtifact référentiel en amont qui ne sont pas présents dans le CodeArtifact référentiel actuel, ils seront conservés dans le référentiel actuel lors pip install de son exécution.

Versions du package supprimées

Certaines versions de package sur pypi.org sont marquées comme supprimées, ce qui indique à l'installateur du package (comme pip) que la version ne doit pas être installée sauf si elle est la seule à correspondre à un spécificateur de version (en utilisant l'un ou l'autre). == === Voir PEP_592 pour plus d'informations.

Si une version de package CodeArtifact a été initialement récupérée à partir d'une connexion externe à pypi.org, lorsque vous installez la version du package depuis un CodeArtifact dépôt, CodeArtifact assurez-vous que les métadonnées supprimées mises à jour de la version du package sont extraites de pypi.org.

Comment savoir si une version de package est supprimée

Pour vérifier si une version du package est intégrée CodeArtifact, vous pouvez essayer de l'installer avecpip install packageName===packageVersion. Si la version du package est supprimée, vous recevrez un message d'avertissement semblable au suivant :

WARNING: The candidate selected for download or install is a yanked version

Pour vérifier si une version du package est supprimée dans pypi.org, vous pouvez consulter la liste pypi.org de la version du package à l'adresse suivante. https://pypi.org/project/packageName/packageVersion/

Configuration du statut de retrait sur les packages privés

CodeArtifact ne prend pas en charge la définition de métadonnées supprimées pour les packages publiés directement dans les CodeArtifact référentiels.

Pourquoi ne CodeArtifact pas récupérer les dernières métadonnées ou ressources supprimées pour une version de package ?

Normalement, CodeArtifact garantit que lorsqu'une version de package Python est extraite d'un CodeArtifact dépôt, les métadonnées extraites ont la dernière valeur sur pypi.org. up-to-date En outre, la liste des actifs de la version du package est également mise à jour avec la dernière version sur pypi.org et sur tous les référentiels en amont CodeArtifact . Cela est vrai si vous installez la version du package pour la première fois et que vous l' CodeArtifact importez depuis pypi.org dans votre CodeArtifact dépôt, ou si vous avez déjà installé le package. Cependant, dans certains cas, le client du gestionnaire de packages, tel que pip, n'extrait pas les dernières métadonnées extraites de pypi.org ou des référentiels en amont. Au lieu de cela, il CodeArtifact renverra les données déjà stockées dans votre référentiel. Cette section décrit les trois manières dont cela peut se produire :

Configuration en amont : si la connexion externe à pypi.org est supprimée du référentiel ou de ses flux en amont à l'aide de pypi.org disassociate-external-connection, les métadonnées supprimées ne seront plus actualisées depuis pypi.org. De même, si vous supprimez un référentiel en amont, les ressources du référentiel supprimé et des ressources en amont du référentiel supprimé ne seront plus disponibles dans le référentiel actuel. Il en va de même si vous utilisez les contrôles d'origine des CodeArtifact packages pour empêcher l'extraction de nouvelles versions d'un package spécifique. Ce paramètre upstream=BLOCK empêchera l'actualisation des métadonnées extraites.

État de la version du package : si vous définissez le statut d'une version de package sur autre chose que « Published ou »Unlisted, les métadonnées et les actifs retirés de la version du package ne seront pas actualisés. De même, si vous récupérez une version de package spécifique (par exempletorch 2.0.1) et que la même version de package est présente dans un référentiel en amont avec un statut qui n'est pas Published ouUnlisted, cela bloquera également les métadonnées extraites et la propagation des actifs du référentiel en amont vers le référentiel actuel. Cela est dû au fait que les autres statuts de version de package indiquent que les versions ne sont plus destinées à être consommées dans aucun référentiel.

Publication directe : si vous publiez une version de package spécifique directement dans un CodeArtifact référentiel, cela empêchera le retrait des métadonnées et l'actualisation des ressources pour la version du package depuis ses référentiels en amont et depuis pypi.org. Supposons, par exemple, que vous téléchargiez une ressource à partir de la version du packagetorch 2.0.1, par exempletorch-2.0.1-cp311-none-macosx_11_0_arm64.whl, à l'aide d'un navigateur Web, puis que vous la publiez dans votre CodeArtifact référentiel à l'aide de twine astorch 2.0.1. CodeArtifact vérifie que la version du package est entrée dans le domaine en la publiant directement dans votre dépôt, et non à partir d'une connexion externe à pypi.org ou d'un dépôt en amont. Dans ce cas, les métadonnées CodeArtifact extraites ne sont pas synchronisées avec les référentiels en amont ou avec pypi.org. Il en va de même si vous publiez torch 2.0.1 dans un référentiel en amont : la présence de la version du package bloquera la propagation des métadonnées et des actifs extraits vers les référentiels situés plus bas dans le graphique en amont.