

Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).

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.

# Concepts de package
<a name="packages-concepts"></a>

Voici quelques concepts et termes à connaître lors de la gestion, de la publication ou de la consommation de packages dans CodeCatalyst.

## Forfaits
<a name="packages-concepts-packages"></a>

Un *package* est un ensemble qui inclut à la fois le logiciel et les métadonnées nécessaires à l'installation du logiciel et à la résolution des dépendances. CodeCatalyst prend en charge le format de package npm.

Un package comprend :
+ Un nom (par exemple, `webpack` c'est le nom d'un package npm populaire)
+ Un espace de [noms](#packages-concepts-package-namespaces) facultatif (par exemple, `@types` dans`@types/node`)
+ Un ensemble de [versions](#packages-concepts-package-versions) (par exemple,`1.0.0`,`1.0.1`,`1.0.2`)
+ Métadonnées au niveau du package (par exemple, balises npm dist)

## Espaces de noms de packages
<a name="packages-concepts-package-namespaces"></a>

Certains formats de package prennent en charge les noms de packages hiérarchiques afin d'organiser les packages en groupes logiques et d'éviter les collisions de noms. Les packages portant le même nom peuvent être stockés dans différents espaces de noms. Par exemple, npm prend en charge les étendues, et le package npm `@types/node` a une portée `@types` et un nom de. `node` Il existe de nombreux autres noms de packages dans le `@types` champ d'application. Dans CodeCatalyst, la portée (« types ») est appelée espace de noms du package, et le nom (« nœud ») est appelé nom du package. Pour les packages Maven, l'espace de noms du package correspond au Maven GroupID. Le package Maven `org.apache.logging.log4j:log4j` possède un groupID (espace de noms de package) `org.apache.logging.log4j` et un artifactID (nom du package). `log4j` Certains formats de package tels que Python ne prennent pas en charge les noms hiérarchiques avec un concept similaire à npm scope ou Maven GroupID. Si vous n'avez aucun moyen de regrouper les noms de packages, il peut être plus difficile d'éviter les collisions de noms.

## Versions de package
<a name="packages-concepts-package-versions"></a>

Une *version de package* identifie la version spécifique d'un package, telle que`@types/node@12.6.9`. Le format et la sémantique du numéro de version varient en fonction des différents formats de package. Par exemple, les versions du package npm doivent être conformes à la spécification de [version sémantique](https://semver.org/). Dans CodeCatalyst, une version de package comprend l'identifiant de version, package-version-level les métadonnées et un ensemble de ressources.

## Assets
<a name="packages-concepts-assets"></a>

Un *actif* est un fichier individuel stocké dans CodeCatalyst lequel est associé à une version de package, tel qu'un fichier npm ou un `.tgz` fichier Maven POM ou JAR.

## Référentiels de packages
<a name="packages-concepts-repository"></a>

Un *référentiel de CodeCatalyst packages* contient un ensemble de [packages](#packages-concepts-packages), qui contiennent des [versions](#packages-concepts-package-versions) de packages, chacune correspondant à un ensemble de [ressources](#packages-concepts-assets). Les référentiels de packages sont polyglottes, ce qui signifie qu'un seul référentiel peut contenir tous les types de packages pris en charge. Chaque référentiel de packages expose des points de terminaison permettant de récupérer et de publier des packages à l'aide d'outils tels que NuGet CLIs (`nuget`,`dotnet`), la `npm` CLI, la CLI Maven (`mvn`) et Python CLIs (et). `pip` `twine` Pour plus d'informations sur les quotas de packages dans CodeCatalyst, notamment le nombre de référentiels de packages pouvant être créés dans chaque espace, consultez[Quotas pour les packages](packages-quotas.md).

Vous pouvez lier un dépôt de packages à un autre en le définissant comme un dépôt amont. Lorsqu'un dépôt est défini comme un dépôt amont, vous pouvez utiliser n'importe quel package en amont ainsi que tous les référentiels en amont supplémentaires de la chaîne. Pour de plus amples informations, veuillez consulter [Référentiels en amont](#packages-concepts-upstream-repositories).

Les référentiels Gateway sont un type spécial de référentiel de packages qui extrait et stocke les packages provenant d'autorités de packages externes officielles. Pour de plus amples informations, veuillez consulter [Référentiels de passerelle](#packages-concepts-gateway-repositories).

## Référentiels en amont
<a name="packages-concepts-upstream-repositories"></a>

Vous pouvez l'utiliser CodeCatalyst pour créer une relation en amont entre deux référentiels de packages. Un référentiel de packages est *situé en amont* d'un autre lorsque les versions de packages qu'il contient sont accessibles depuis le point de terminaison du référentiel de packages du référentiel en aval. Dans le cadre d'une relation en amont, le contenu des deux référentiels de packages est efficacement fusionné du point de vue du client.

Par exemple, si un gestionnaire de packages demande une version de package qui n'existe pas dans un référentiel, il CodeCatalyst recherchera alors la version du package dans les référentiels en amont configurés. Les référentiels en amont sont recherchés dans l'ordre dans lequel ils sont configurés et, une fois qu'un package est trouvé, la recherche CodeCatalyst s'arrête. 

## Référentiels de passerelle
<a name="packages-concepts-gateway-repositories"></a>

Un *dépôt de passerelle* est un type spécial de dépôt de packages connecté à une autorité de package externe officielle prise en charge. Lorsque vous ajoutez un référentiel de passerelle [en tant que référentiel en amont](#packages-concepts-upstream-repositories), vous pouvez consommer des packages provenant de l'autorité officielle des packages correspondante. Votre référentiel en aval ne communique pas avec le référentiel public. Au contraire, tout est intermédiaire par le référentiel de passerelle. Les packages consommés de cette manière sont stockés à la fois dans le référentiel de passerelle et dans le référentiel en aval qui a reçu la demande initiale.

Les référentiels Gateway sont prédéfinis, mais ils doivent être créés dans chaque projet pour être utilisés. La liste suivante contient tous les référentiels de passerelle qui peuvent être créés CodeCatalyst et l'autorité de package à laquelle ils sont connectés.
+ **npm-public-registry-gateway**fournit des packages npm de npmjs.com.
+ **maven-central-gateway**fournit des packages Maven à partir du référentiel Maven Central.
+ **google-android-gateway**fournit des packages Maven à partir de Google Android.
+ **commonsware-gateway** fournit des packages Maven à partir de. CommonsWare
+ **gradle-plugins-gateway**fournit des packages Maven à partir de Gradle Plugins.
+ **nuget-gallery-gateway**fournit des NuGet packages provenant de la NuGet galerie.
+ **pypi-gateway fournit des** packages Python à partir de l'index des packages Python.