

Amazon ya no CodeCatalyst está abierto a nuevos clientes. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cómo migrar desde CodeCatalyst](migration.md).

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Conceptos sobre paquetes
<a name="packages-concepts"></a>

Estos son algunos conceptos y términos que debes conocer a la hora de gestionar, publicar o consumir paquetes CodeCatalyst.

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

Un *paquete* es un paquete que incluye el software y los metadatos necesarios para instalar el software y resolver cualquier dependencia. CodeCatalyst admite el formato de paquete npm.

Un paquete se compone de lo siguiente:
+ Un nombre (por ejemplo, `webpack` es el nombre de un paquete npm conocido).
+ Un [espacio de nombres](#packages-concepts-package-namespaces) opcional (por ejemplo, `@types` en `@types/node`).
+ Un conjunto de [versiones](#packages-concepts-package-versions) (por ejemplo, `1.0.0`, `1.0.1` o `1.0.2`).
+ Metadatos en el nivel del paquete (por ejemplo, etiquetas dist de npm).

## Espacios de nombres en paquetes
<a name="packages-concepts-package-namespaces"></a>

Algunos formatos de paquetes admiten nombres de paquetes jerárquicos para organizar los paquetes en grupos lógicos y evitar colisiones de nombres. Los paquetes que tienen el mismo nombre se pueden almacenar en diferentes espacios de nombres. Por ejemplo, npm admite ámbitos: el paquete npm `@types/node` tiene un ámbito `@types` y un nombre `node`. Hay muchos otros nombres de paquetes en el alcance `@types`. En CodeCatalyst, el ámbito («tipos») se denomina espacio de nombres del paquete y el nombre («nodo») se denomina nombre del paquete. En el caso de los paquetes de Maven, el espacio de nombres del paquete corresponde al ID de grupo de Maven. El paquete Maven `org.apache.logging.log4j:log4j` tiene un groupID (espacio de nombres del paquete) de `org.apache.logging.log4j` y un artifactID (nombre del paquete) `log4j`. Algunos formatos de paquetes, como Python, no admiten nombres jerárquicos con un concepto similar al alcance de npm o al ID de grupo de Maven. Sin una forma de agrupar los nombres de los paquetes, puede resultar más difícil evitar las colisiones de nombres.

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

La *versión de un paquete* identifica la versión específica de un paquete, por ejemplo `@types/node@12.6.9`. El formato y la semántica del número de versión varían según los distintos formatos de paquete. Por ejemplo, las versiones del paquete npm deben cumplir con la [especificación de control de versiones semántico](https://semver.org/). En CodeCatalyst, la versión de un paquete consta del identificador de la versión, package-version-level los metadatos y un conjunto de activos.

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

Un *activo* es un archivo individual almacenado en el CodeCatalyst que se asocia a una versión de paquete, como un archivo npm o un `.tgz` archivo POM o JAR de Maven.

## Repositorios de paquetes
<a name="packages-concepts-repository"></a>

[Un *repositorio de CodeCatalyst paquetes* contiene un conjunto de [paquetes](#packages-concepts-packages), que contienen [versiones de paquetes](#packages-concepts-package-versions), cada una de las cuales se asigna a un conjunto de activos.](#packages-concepts-assets) Los repositorios de paquetes son políglotas, lo que significa que un único repositorio puede contener paquetes de cualquier tipo compatible. Cada repositorio de paquetes expone puntos finales para obtener y publicar paquetes mediante herramientas como NuGet CLIs (`nuget`,`dotnet`), la CLI, la `npm` CLI de Maven (`mvn`) y Python CLIs (y). `pip` `twine` Para obtener información sobre las cuotas de paquetes CodeCatalyst, incluido el número de repositorios de paquetes que se pueden crear en cada espacio, consulte. [Cuotas para paquetes](packages-quotas.md)

Puede vincular un repositorio de paquetes a otro configurándolo como ascendente. Cuando un repositorio está configurado como ascendente, puede usar cualquiera de sus paquetes, así como cualquier repositorio ascendente adicional en la cadena. Para obtener más información, consulte [Repositorios ascendentes](#packages-concepts-upstream-repositories).

Los repositorios de puerta de enlace son un tipo especial de repositorio de paquetes que extrae y almacena paquetes de las autoridades de paquetes oficiales y externas. Para obtener más información, consulte [Repositorios de puerta de enlace](#packages-concepts-gateway-repositories).

## Repositorios ascendentes
<a name="packages-concepts-upstream-repositories"></a>

Se puede utilizar CodeCatalyst para crear una relación ascendente entre dos repositorios de paquetes. Un repositorio es *ascendente* con respecto a otro cuando se puede acceder a las versiones de los paquetes que contiene desde el punto de conexión del repositorio descendente. En una relación ascendente, el contenido de los dos repositorios de paquetes se combina desde el punto de vista de un cliente.

Por ejemplo, si un administrador de paquetes solicita una versión de paquete que no existe en un repositorio, CodeCatalyst buscará la versión del paquete en los repositorios ascendentes configurados. Los repositorios ascendentes se buscan en el orden en que están configurados y, una vez que se encuentra un paquete, CodeCatalyst se detiene la búsqueda. 

## Repositorios de puerta de enlace
<a name="packages-concepts-gateway-repositories"></a>

Un *repositorio de puerta de enlace* es un tipo especial de repositorio de paquetes que está conectado a una autoridad de paquetes oficial y externa compatible. Al añadir un repositorio de puerta de enlace como [repositorio ascendente](#packages-concepts-upstream-repositories), puede consumir paquetes de la autoridad de paquetes oficial correspondiente. El repositorio descendente no se comunica con el repositorio público: el repositorio de puerta de enlace hace de intermediario. Los paquetes que se consumen de esta manera se almacenan tanto en el repositorio de puerta de enlace como en el repositorio descendente que recibió la solicitud original.

Los repositorios de puerta de enlace están predefinidos, pero deben crearse en cada proyecto que se vaya a utilizar. La siguiente lista contiene todos los repositorios de puerta de enlace en los que se pueden crear CodeCatalyst y la autoridad de paquetes a la que están conectados.
+ **npm-public-registry-gateway**proporciona paquetes npm de npmjs.com.
+ **maven-central-gateway**proporciona paquetes Maven del repositorio central de Maven.
+ **google-android-gateway**proporciona paquetes Maven de Google Android.
+ **commonsware-gateway** proporciona paquetes Maven desde. CommonsWare
+ **gradle-plugins-gateway**proporciona paquetes Maven de Gradle Plugins.
+ **nuget-gallery-gateway**proporciona NuGet paquetes de la NuGet Galería.
+ **pypi-gateway** proporciona paquetes Python desde Python Package Index.