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
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
Si une version de package CodeArtifact a été initialement récupérée à partir d'une connexion externe à 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
. Si la version du package est supprimée, vous recevrez un message d'avertissement semblable au suivant :packageName
===packageVersion
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.orghttps://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
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.