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.
# Publica y comparte paquetes de software en CodeCatalyst
Amazon CodeCatalyst incluye un servicio de repositorio de paquetes totalmente gestionado que permite a su equipo de desarrollo almacenar y compartir de forma segura los paquetes de software utilizados para el desarrollo de aplicaciones. Estos paquetes se almacenan en repositorios de paquetes, que se crean y organizan dentro de los CodeCatalyst proyectos.
Un único repositorio de paquetes puede almacenar paquetes de todos los tipos de paquetes compatibles. CodeCatalyst admite los siguientes formatos de paquetes:
+ npm
+ Maven
+ NuGet
+ Python
Los paquetes de un repositorio de paquetes se pueden detectar y compartir entre los miembros del proyecto donde está el repositorio.
Para publicar paquetes y consumir paquetes de un repositorio, configure el administrador de paquetes para el uso del punto de conexión (URL) del repositorio. A continuación, puede usar el administrador de paquetes para publicar paquetes en el repositorio. Puede usar administradores de paquetes como Maven, Gradle, npm, yarn, nuget, dotnet, pip y twine.
También puede configurar los CodeCatalyst flujos de trabajo para usar repositorios de CodeCatalyst paquetes. Para obtener más información sobre el uso de paquetes en flujos de trabajo, consulte [Conexión de repositorios de paquetes a flujos de trabajo](workflows-packages.md).
Puede hacer que los paquetes de un repositorio de paquetes estén disponibles para otro repositorio del mismo proyecto añadiéndolo como repositorio ascendente. Todas las versiones de paquetes disponibles en el repositorio ascendente también están disponibles en el repositorio descendente. Para obtener más información, consulte [Configuración y uso de repositorios ascendentes](packages-upstream-repositories.md).
**Puedes hacer que los paquetes de código abierto estén disponibles en tu CodeCatalyst repositorio creando un tipo especial de repositorio denominado puerta de enlace.** La transmisión a un repositorio de puerta de enlace te permite consumir paquetes de repositorios públicos populares, como npmjs.com y pypi.org, y guardarlos automáticamente en caché en tu repositorio. CodeCatalyst Para obtener más información, consulte [Conexión a repositorios públicos externos](packages-connect-external.md).
**Topics**
+ [Conceptos sobre paquetes](packages-concepts.md)
+ [Configuración y uso de repositorios de paquetes](packages-repositories.md)
+ [Configuración y uso de repositorios ascendentes](packages-upstream-repositories.md)
+ [Conexión a repositorios públicos externos](packages-connect-external.md)
+ [Publicación y modificación de paquetes](working-with-packages.md)
+ [Con npm](packages-npm.md)
+ [Uso de Maven](packages-maven.md)
+ [Uso NuGet](packages-nuget.md)
+ [Uso de Python](packages-python.md)
+ [Cuotas para paquetes](packages-quotas.md)
# Conceptos sobre paquetes
Estos son algunos conceptos y términos que debes conocer a la hora de gestionar, publicar o consumir paquetes CodeCatalyst.
## Paquetes
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
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
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
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
[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
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
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.
# Configuración y uso de repositorios de paquetes
En CodeCatalyst, los paquetes se almacenan y administran en repositorios de paquetes. Para publicar paquetes en un repositorio de paquetes CodeCatalyst o consumirlos de uno CodeCatalyst (o de cualquier repositorio de paquetes público compatible), debe crear un repositorio de paquetes y conectar su administrador de paquetes a él.
**Topics**
+ [Creación de un repositorio de paquetes](packages-repositories-create.md)
+ [Conexión a un repositorio de paquetes](packages-repositories-connect.md)
+ [Eliminación de un repositorio de paquetes](packages-repositories-delete.md)
# Creación de un repositorio de paquetes
Realice los siguientes pasos para crear un repositorio de paquetes en CodeCatalyst.
**Creación de un repositorio de paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Vaya al proyecto en el que quiera crear un repositorio de paquetes.
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, seleccione **Crear repositorio de paquetes**.
1. En la sección **Detalles del repositorio de paquetes**, añada lo siguiente:
1. **Nombre del repositorio**. Valore la posibilidad de usar un nombre descriptivo, con detalles sobre el nombre del proyecto o el equipo o sobre cómo se usará el repositorio.
1. (Opcional) **Descripción**. Una descripción del repositorio es especialmente útil cuando tiene varios repositorios en varios equipos de un proyecto.
1. En la sección **Repositorios ascendentes, selecciona Seleccionar repositorios** **ascendentes para añadir los repositorios** de paquetes a los que quieras acceder a través de tu repositorio de paquetes. CodeCatalyst **Puedes añadir repositorios **Gateway para conectarte a repositorios** de paquetes externos o a otros repositorios. CodeCatalyst **
1. Cuando se solicita un paquete desde un repositorio de paquetes, se buscarán en los repositorios ascendentes en el orden en el que aparecen en esta lista. Una vez que se encuentre un paquete, CodeCatalyst dejará de buscar. Para cambiar el orden de los repositorios ascendentes, puede arrastrarlos y soltarlos en la lista.
1. Elija **Crear** para crear un repositorio de paquetes.
# Conexión a un repositorio de paquetes
Para publicar o consumir paquetes desde CodeCatalyst, debe configurar su administrador de paquetes con la información y las CodeCatalyst credenciales del punto final del repositorio de paquetes. Si no ha creado un repositorio, puede hacerlo siguiendo las instrucciones en [Creación de un repositorio de paquetes](packages-repositories-create.md).
Para obtener instrucciones sobre cómo conectar un administrador de paquetes a un repositorio de CodeCatalyst paquetes, consulta la siguiente documentación.
+ [Configuración y uso de Gradle Groovy](packages-maven-gradle.md)
+ [Configuración y uso de mvn](packages-maven-mvn.md)
+ [Configuración y uso de la CLI de nuget o dotnet](packages-nuget-cli.md)
+ [Configuración y uso de npm](packages-npm-use.md)
+ [Configuración de pip e instalación de paquetes de Python](packages-python-pip.md)
+ [Configuración de Twine y publicación de paquetes de Python](packages-python-twine.md)
# Eliminación de un repositorio de paquetes
Realice los siguientes pasos para eliminar un repositorio de paquetes en CodeCatalyst.
**Eliminación de un repositorio de paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Vaya al proyecto que contenga el repositorio de paquetes que desee eliminar.
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que desee eliminar.
1. Elija **Eliminar**.
1. Revise la información proporcionada sobre los efectos de eliminar un repositorio de paquetes.
1. Escriba `delete` en el campo de entrada y elija **Eliminar**.
# Configuración y uso de repositorios ascendentes
Puede conectar tanto los repositorios de puerta de enlace como otros repositorios de CodeCatalyst paquetes como archivos ascendentes a sus repositorios de paquetes. Esto permite que el cliente administrador de paquetes acceda a los paquetes que están contenidos en más de un repositorio de paquetes mediante un único punto de conexión de repositorio de paquetes. Estas son las principales ventajas de utilizar repositorios ascendentes:
+ Solo tiene que configurar su administrador de paquetes con un único punto de conexión de repositorio para extraerlos de múltiples orígenes.
+ Los paquetes consumidos de un repositorio ascendente se almacenan en el repositorio descendente, lo que garantiza que los paquetes estarán disponibles aunque el repositorio ascendente sufra interrupciones inesperadas y aunque se eliminen los paquetes del repositorio ascendente.
Puede añadir repositorios ascendentes al crear un repositorio de paquetes. También puedes añadir o eliminar repositorios anteriores de los repositorios de paquetes existentes en la consola. CodeCatalyst
Al añadir un repositorio de puerta de enlace como repositorio ascendente, el repositorio de paquetes se conectará al repositorio de paquetes público correspondiente del repositorio de puerta de enlace. Para ver una lista de los repositorios de paquetes públicos compatibles, consulte [Repositorios de paquetes externos compatibles y sus repositorios de puerta de enlace](packages-connect-external.md#packages-upstream-repositories-supported-external).
Puede vincular varios repositorios como repositorios ascendentes. Por ejemplo, supongamos que tu equipo crea un repositorio con el nombre `project-repo` y ya está utilizando otro repositorio con el nombre `team-repo` **npm-public-registry-gateway**agregado como repositorio ascendente, que está conectado al repositorio público de npm,. `npmjs.com` Puede añadir `team-repo` como repositorio ascendente en `project-repo`. En este caso, solo tiene que configurar su administrador de paquetes para que use `project-repo` a fin de extraer paquetes de `project-repo`, `team-repo`, `npm-public-registry-gateway` y `npmjs.com`.
**Topics**
+ [Adición de un repositorio ascendente](packages-upstream-repositories-add.md)
+ [Edición del orden de búsqueda de repositorios ascendentes](packages-upstream-repositories-search-order.md)
+ [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md)
+ [Eliminación de un repositorio ascendente](packages-upstream-repositories-remove.md)
# Adición de un repositorio ascendente
Al agregar un repositorio de paquetes público u otro CodeCatalyst repositorio de paquetes como repositorio ascendente a su repositorio descendente, todos los paquetes del repositorio ascendente estarán disponibles para los administradores de paquetes que estén conectados al repositorio descendente.
**Adición de un repositorio ascendente**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio de paquetes al que desea añadir un repositorio ascendente.
1. En el nombre del repositorio de paquetes, seleccione **Ascendentes** y **Seleccionar repositorios ascendentes**.
1. En **Seleccionar el tipo ascendente**, elija una de las siguientes opciones:
+ **Repositorios de puerta de enlace**
Puede elegir de una lista de repositorios de puerta de enlace disponibles.
**nota**
Para conectarse a organismos públicos de paquetería externos, como Maven Central, npmjs.com o Nuget Gallery, CodeCatalyst utiliza los repositorios de puerta de enlace como repositorios intermediarios que buscan y almacenan los paquetes extraídos de repositorios externos. Esto ahorra tiempo y transferencia de datos, ya que todos los repositorios de paquetes de un proyecto pueden usar los paquetes almacenados en el repositorio de puerta de enlace. Para obtener más información, consulte [Conexión a repositorios públicos externos](packages-connect-external.md).
+ **CodeCatalyst repositorios**
Puede elegir entre una lista de repositorios de CodeCatalyst paquetes disponibles en su proyecto.
1. Cuando haya seleccionado todos los repositorios que desee añadir como repositorios ascendentes, elija **Seleccionar** y **Guardar**.
Para obtener más información sobre cómo cambiar el orden de búsqueda de los repositorios ascendentes, consulte [Edición del orden de búsqueda de repositorios ascendentes](packages-upstream-repositories-search-order.md).
Cuando haya añadido un repositorio ascendente, podrá usar un administrador de paquetes que esté conectado al repositorio local para obtener paquetes del repositorio ascendente. No necesita actualizar la configuración del administrador de paquetes. Para obtener más información sobre cómo solicitar versiones de paquetes desde un repositorio ascendente, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
# Edición del orden de búsqueda de repositorios ascendentes
CodeCatalyst busca en los repositorios ascendentes en el orden de búsqueda configurado. Cuando se encuentra un paquete, CodeCatalyst deja de buscar. Puede cambiar el orden en el que se buscan los paquetes en los repositorios ascendentes.
**Edición del orden de búsqueda en repositorios ascendentes**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio de paquetes donde desee editar el orden de búsqueda para repositorios ascendentes.
1. En el nombre del repositorio de paquetes, seleccione **Ascendentes**.
1. En la sección **Repositorios ascendentes**, puede ver los repositorios ascendentes y su orden de búsqueda. Para cambiar el orden de búsqueda, arrastre y suelte los repositorios en la lista.
1. Cuando haya terminado de editar el orden de búsqueda en los repositorios ascendentes, elija **Guardar**.
# Solicitar una versión de paquete con repositorios ascendentes
El siguiente ejemplo muestra los posibles escenarios en los que un administrador de paquetes solicita un paquete de un repositorio de CodeCatalyst paquetes que tiene repositorios ascendentes.
En este ejemplo, un administrador de paquetes, como `npm`, solicita una versión de paquete desde un repositorio de paquetes denominado `downstream`, que tiene muchos repositorios ascendentes. Cuando se solicita el paquete, puede ocurrir lo siguiente:
+ Si `downstream` contiene la versión del paquete solicitada, se devuelve al cliente.
+ Si `downstream` no contiene la versión del paquete solicitada, la CodeCatalyst busca en sus repositorios `downstream` principales, en el orden de búsqueda configurado. Si se encuentra la versión del paquete, se copia una referencia a la misma en `downstream` y la versión del paquete se devuelve al cliente.
+ Si ni `downstream` ni sus repositorios ascendentes contienen la versión del paquete, se devuelve una respuesta HTTP 404 `Not Found` al cliente.
El número máximo de repositorios ascendentes directos permitidos para un repositorio es 10. El número máximo de CodeCatalyst búsquedas en los repositorios cuando se solicita una versión de paquete es de 25.
## Retención de paquetes de repositorios ascendentes
Si la versión de un paquete solicitada se encuentra en un repositorio ascendente, se conservará una referencia a la misma, que estará siempre disponible en el repositorio que la solicitó. Esto garantiza que tenga acceso a los paquetes en caso de que haya una interrupción inesperada del repositorio ascendente. La versión del paquete retenida no se ve afectada por ninguno de los siguientes factores:
+ Eliminar el repositorio ascendente.
+ Desconectar el repositorio ascendente del repositorio descendente.
+ Eliminar la versión del paquete del repositorio ascendente.
+ Editar la versión del paquete en el repositorio ascendente (por ejemplo, añadiéndole un nuevo activo).
## Obtención de paquetes a través de una relación ascendente
CodeCatalyst puede buscar paquetes a través de varios repositorios enlazados denominados repositorios ascendentes. Si un repositorio de CodeCatalyst paquetes tiene una conexión ascendente a otro repositorio de CodeCatalyst paquetes que tiene una conexión ascendente a un repositorio de puerta de enlace, las solicitudes de paquetes que no estén en el repositorio ascendente se copian del repositorio externo. Por ejemplo, considere la siguiente configuración: un repositorio denominado `repo-A` tiene una conexión ascendente con el repositorio de puerta de enlace,. `npm-public-registry-gateway` `npm-public-registry-gateway`tiene una conexión ascendente al repositorio público de paquetes,. [https://npmjs.com](https://npmjs.com)
![\[Diagrama sencillo de un repositorio ascendente que muestra tres repositorios encadenados.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/upstream-with-external.png)
Si `npm` está configurado para usar el `repo-A` repositorio, la ejecución `npm install` inicia la copia de los paquetes desde [https://npmjs.com](https://npmjs.com)dentro. `npm-public-registry-gateway` También se incluyen las versiones instaladas`repo-A`. El siguiente ejemplo instala `lodash`.
```
$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s
```
Tras ejecutar `npm install`, `repo-A` contiene solo la versión más reciente (`lodash 4.17.20`), ya que esa es la versión que `npm` ha obtenido desde `repo-A`.
Como `npm-public-registry-gateway` tiene una conexión ascendente externa a [https://npmjs.com](https://npmjs.com), todas las versiones de los paquetes desde las que se importan se [https://npmjs.com](https://npmjs.com)almacenan en él. `npm-public-registry-gateway` Estas versiones de paquetes podrían haber sido recuperadas por cualquier repositorio descendente con una conexión ascendente que llevase a `npm-public-registry-gateway`.
El contenido de `npm-public-registry-gateway` le permite ver todos los paquetes y las versiones de los paquetes que se han importado a [https://npmjs.com](https://npmjs.com)lo largo del tiempo.
## Retención de paquetes en repositorios intermedios
CodeCatalyst permite encadenar repositorios ascendentes. Por ejemplo, `repo-A` puede tener a `repo-B` como flujo ascendente y `repo-B` puede tener a `repo-C` como flujo ascendente. Esta configuración hace que las versiones del paquete en `repo-B` y `repo-C` estén disponibles de `repo-A`.
![\[Diagrama sencillo de un repositorio ascendente que muestra tres repositorios encadenados.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/upstream-chaining.png)
Cuando un administrador de paquetes se conecta al repositorio `repo-A` y obtiene una versión de paquete del repositorio `repo-C`, la versión del paquete no se conserva en el repositorio `repo-B`. La versión del paquete solo se conserva en el repositorio descendente más lejano; en este caso, `repo-A`. No se conservará en ningún repositorio intermedio. Esto también es válido para cadenas más largas; por ejemplo, si hubiera cuatro repositorios (`repo-A`, `repo-B`, `repo-C` y `repo-D`) y un administrador de paquetes conectado a `repo-A` extrajera una versión de paquete de `repo-D`, la versión del paquete se conservaría en `repo-A`, pero no en `repo-B` ni en `repo-C`.
El comportamiento de retención de paquetes es similar al de la extracción de una versión de paquete de un repositorio externo, con la diferencia de que la versión del paquete siempre se conserva en el repositorio de puerta de enlace que tenga la conexión ascendente directa al repositorio externo. Por ejemplo, `repo-A` tiene a `repo-B` como repositorio ascendente. `repo-B` tiene a `npm-public-registry-gateway` como repositorio ascendente, que tiene una conexión ascendente con el repositorio público **npmjs.com**; consulte el siguiente diagrama.
![\[Diagrama de repositorios ascendentes, con tres repositorios encadenados entre sí con una conexión externa ascendente a npmjs.com.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/upstream-chaining-external.png)
Si un administrador de paquetes conectado a `repo-A` solicita una versión de paquete específica, como *lodash 4.17.20*, y la versión del paquete no está en ninguno de los tres repositorios, se obtendrá de **npmjs.com**. Al obtener *lodash 4.17.20*, este se conserva en `repo-A`, ya que es el repositorio descendente más lejano, y en `npm-public-registry-gateway`, ya que tiene conectada la conexión ascendente al repositorio público externo (**npmjs.com**). *lodash 4.17.20* no se conservará en `repo-B` porque es un repositorio intermedio.
# Eliminación de un repositorio ascendente
Si ya no desea acceder a los paquetes de un repositorio ascendente, puede eliminar el repositorio ascendente del repositorio de paquetes.
**aviso**
Al eliminar un repositorio ascendente, se podría romper la cadena de relaciones ascendentes, lo que podría interrumpir los proyectos o las compilaciones.
**Eliminación de un repositorio ascendente**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio de paquetes del que desea eliminar un repositorio ascendente.
1. En el nombre del repositorio de paquetes, seleccione **Ascendentes**.
1. En **Editar repositorios ascendentes**, busque el repositorio ascendente que desea eliminar y seleccione ![\[Remove\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/remove.png).
1. Cuando haya terminado de ordenar los repositorios ascendentes, elija **Guardar**.
# Conexión a repositorios públicos externos
Puede conectar los repositorios de CodeCatalyst paquetes a los repositorios externos públicos compatibles añadiendo el repositorio de puerta de enlace correspondiente como repositorio ascendente. Los repositorios de puerta de enlace actúan como repositorios intermediarios que buscan y almacenan paquetes extraídos de repositorios externos. Esto ahorra tiempo y transferencia de datos, ya que todos los repositorios de paquetes de un proyecto pueden usar los paquetes almacenados en el repositorio de puerta de enlace.
**Conexión a un repositorio público mediante repositorios de puerta de enlace**
1. En el panel de navegación, elija **Paquetes**.
1. En **Paquetes**, seleccione la página **Repositorios de puerta de enlace**. Puede ver una lista de los repositorios de puerta de enlace compatibles y sus descripciones.
1. Para usar un repositorio de puerta de enlace, primero debe crearlo. Si se ha creado el repositorio de puerta de enlace, podrá ver la fecha y la hora de la creación. Si no se ha creado, seleccione **Crear**.
1. Para usar los paquetes del repositorio de la puerta de enlace, debes establecer una conexión ascendente al repositorio desde un repositorio. CodeCatalyst Seleccione **Repositorios de paquetes** y elija el repositorio de paquetes al que desee conectarse.
1. Para conectarse al repositorio público, seleccione **Ascendentes** y **Seleccionar repositorios ascendentes**.
1. Elija **Repositorios de puerta de enlace** y seleccione el repositorio de puerta de enlace que corresponda al repositorio público al que desea conectarse como repositorio ascendente.
1. Cuando haya seleccionado todos los repositorios de puerta de enlace que desee añadir como repositorios ascendentes, elija **Seleccionar**.
1. Cuando haya terminado de ordenar los repositorios ascendentes, elija **Guardar**.
Para obtener más información sobre los repositorios ascendentes, consulte [Configuración y uso de repositorios ascendentes](packages-upstream-repositories.md).
Cuando haya añadido un repositorio de puerta de enlace como repositorio ascendente, podrá usar un administrador de paquetes que esté conectado al repositorio local para obtener paquetes del repositorio de paquetes público y externo que le corresponda. No necesita actualizar la configuración del administrador de paquetes. Los paquetes que se consumen de esta manera se almacenan tanto en el repositorio de puerta de enlace como en el repositorio de paquetes local. Para obtener más información sobre cómo solicitar versiones de paquetes desde un repositorio ascendente, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
## Repositorios de paquetes externos compatibles y sus repositorios de puerta de enlace
CodeCatalyst admite la adición de una conexión ascendente a las siguientes autoridades oficiales de paquetes con repositorios de puertas de enlace.
| Tipo de paquete de repositorio | Description (Descripción) | Nombre del repositorio de puerta de enlace |
| --- | --- | --- |
| npm | registro público de npm | npm-public-registry-gateway |
| Python | Índice de paquetes de Python | pypi-gateway |
| Maven | Central de Maven | maven-central-gateway |
| Maven | Repositorio de Google de Android | google-android-gateway |
| Maven | CommonsWare | commonsware-gateway |
| Maven | Repositorio de complementos de Gradle | gradle-plugins-gateway |
| NuGet | NuGet Galería | nuget-gallery-gateway |
# Publicación y modificación de paquetes
Un *paquete* CodeCatalyst es un paquete de software y los metadatos necesarios para resolver las dependencias e instalar el software. Para obtener una lista de los formatos de paquete compatibles CodeCatalyst, consulte[Publica y comparte paquetes de software en CodeCatalyst](packages.md). Esta sección proporciona información sobre la publicación, la visualización, la eliminación de paquetes y la actualización del estado de una versión del paquete.
**Topics**
+ [Publicar paquetes en un repositorio de CodeCatalyst paquetes](package-publishing.md)
+ [Visualización de detalles de la versión del paquete](working-with-packages-view.md)
+ [Eliminación de una versión del paquete](working-with-packages-delete.md)
+ [Actualización del estado de la versión de un paquete](working-with-packages-update-version-status.md)
+ [Edición de los controles de origen de los paquetes](package-origin-controls.md)
# Publicar paquetes en un repositorio de CodeCatalyst paquetes
Puede publicar versiones de cualquier tipo de paquete compatible en un repositorio de CodeCatalyst paquetes mediante las herramientas del administrador de paquetes. Los pasos para publicar una versión del paquete son los siguientes:
**Para publicar una versión de paquete en un repositorio de CodeCatalyst paquetes**
1. Si no lo ha hecho, [cree un repositorio de paquetes](packages-repositories-create.md).
1. Conecte el administrador de paquetes al repositorio de paquetes. Para obtener instrucciones sobre cómo conectar el administrador de paquetes npm a un repositorio de CodeCatalyst paquetes, consulte[Configuración y uso de npm](packages-npm-use.md).
1. Utilice el administrador de paquetes conectado para publicar las versiones de los paquetes.
**Contents**
+ [Repositorios editoriales y originales](#package-publishing-upstreams)
+ [Paquetes privados y repositorios públicos](#package-publishing-upstreams-direct)
+ [Sobrescribir los activos del paquete](#package-publishing-overwrite-assets)
## Repositorios editoriales y originales
En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o repositorios públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm (`lodash@1.0`) en un repositorio de paquetes (`myrepo`), y que `myrepo` está conectado a npmjs.com a través de un repositorio de puerta de enlace configurado como repositorio ascendente. Si `lodash@1.0` está presente en el repositorio original o en npmjs.com, CodeCatalyst rechaza cualquier intento de publicación en él emitiendo un error 409 de conflicto. `myrepo` Esto ayuda a evitar la publicación accidental de un paquete con el mismo nombre y la misma versión que un paquete en un repositorio ascendente, lo que puede provocar un comportamiento inesperado.
Puede seguir publicando diferentes versiones del nombre de un paquete que esté en un repositorio ascendente. Por ejemplo, si `lodash@1.0` está en un repositorio ascendente, pero `lodash@1.1` no, puede publicar `lodash@1.1` en el repositorio descendente.
## Paquetes privados y repositorios públicos
CodeCatalyst no publica los paquetes almacenados en CodeCatalyst repositorios públicos, como npmjs.com o Maven Central. CodeCatalyst importa paquetes de repositorios públicos a un CodeCatalyst repositorio, pero no los mueve en la dirección opuesta. Los paquetes que publiques en los CodeCatalyst repositorios permanecen privados y solo están disponibles para el CodeCatalyst proyecto al que pertenece el repositorio.
## Sobrescribir los activos del paquete
No puede volver a publicar un activo de paquete que ya existe con un contenido diferente. Por ejemplo, suponga que ya publicó un paquete de Maven con un activo `mypackage-1.0.jar` JAR. Solo puede volver a publicar ese activo si la suma de comprobación de los activos antiguos y nuevos es idéntica. Para volver a publicar el mismo activo con contenido nuevo, elimine primero la versión del paquete. Si intenta volver a publicar el mismo nombre de activo con un contenido diferente, se producirá un error de conflicto con el protocolo HTTP 409.
Para los formatos de paquetes que admiten varios activos (Python y Maven), puede añadir nuevos activos con nombres diferentes a una versión de paquete existente en cualquier momento, siempre que tenga los permisos necesarios. Dado que npm NuGet solo admite un activo por versión de paquete, para modificar una versión de paquete publicada, primero debes eliminarla.
Si intenta volver a publicar un activo que ya existe (por ejemplo, `mypackage-1.0.jar`) y el contenido del activo publicado y el nuevo son idénticos, la operación se realizará correctamente porque la operación es idempotente.
# Visualización de detalles de la versión del paquete
Puede usar la CodeCatalyst consola para ver los detalles sobre una versión de paquete específica.
**Visualización de detalles de la versión del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete cuyos detalles quiera ver.
1. Busque la versión del paquete en la tabla **Paquetes**. Puede utilizar la barra de búsqueda para filtrar paquetes por nombre y formato. Elija el paquete en la lista.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera ver.
# Eliminación de una versión del paquete
Puede eliminar una versión del paquete desde la página de **detalles de la versión del paquete** de la CodeCatalyst consola.
**Eliminación de una versión del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete que desee eliminar.
1. Busque y seleccione el paquete en la tabla.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera eliminar.
1. En la página **Detalles de la versión del paquete**, seleccione **Acciones de versión** y después seleccione **Eliminar**.
1. Escriba *delete* en el cuadro de texto y elija **Eliminar**.
# Actualización del estado de la versión de un paquete
Cada versión del paquete CodeCatalyst tiene un estado que describe el estado actual y la disponibilidad de la versión del paquete. Puede cambiar el estado de la versión del paquete en la CodeCatalyst consola. Para obtener más información sobre los posibles valores de estado de las versiones de los paquetes y sus significados, consulte [Estado de la versión del paquete](#package-version-status).
**Actualización del estado de la versión de un paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete cuyo estado quiera actualizar.
1. Busque y seleccione el paquete en la tabla.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera ver.
1. En la página **Detalles de la versión del paquete**, elija **Acciones** y seleccione **Quitar de la lista**, **Archivar** o **Desechar**. Para obtener información sobre el estado de cada versión del paquete, consulte [Estado de la versión del paquete](#package-version-status).
1. Introduzca el texto de confirmación en el campo de texto y seleccione **Quitar de la lista**, **Archivar** o **Desechar**, según el estado de destino de la actualización.
## Estado de la versión del paquete
Los siguientes son valores posibles para el estado de la versión del paquete. Puede cambiar el estado de la versión del paquete en la consola. Para obtener más información, consulte [Actualización del estado de la versión de un paquete](#working-with-packages-update-version-status).
+ **Publicada**: la versión del paquete se publicó correctamente y se puede solicitar mediante un administrador de paquetes. La versión del paquete se incluirá en las listas de versiones de los paquetes devueltas a los administradores de paquetes, por ejemplo, en la salida de `npm view versions`. Todos los activos de la versión del paquete están disponibles en el repositorio.
+ **Sin terminar**: el último intento de publicación no se completó. Actualmente, solo las versiones de paquetes de Maven pueden tener un estado **Sin terminar**. Esto puede ocurrir cuando el cliente carga uno o más activos para una versión del paquete, pero no publica un archivo `maven-metadata.xml` para el paquete que incluye esa versión.
+ **Sin enumerar**: los activos de la versión del paquete están disponibles para su descarga desde el repositorio, pero la versión del paquete no se incluye en la lista de versiones devueltas a los administradores de paquetes. Por ejemplo, en el caso de un paquete npm, la salida de `npm view versions` no incluye la versión del paquete. Esto significa que la lógica de resolución de dependencias de npm no selecciona la versión del paquete porque la versión no aparece en la lista de versiones disponibles. Sin embargo, si ya se hace referencia a la versión del paquete **Sin enumerar** en un archivo `npm package-lock.json`, aún se puede descargar e instalar, por ejemplo, cuando se ejecuta `npm ci`.
+ **Archivado**: los activos de la versión del paquete no se pueden descargar. La versión del paquete no se incluirá en la lista de versiones devueltas a los administradores de paquetes. Como los activos no están disponibles, los clientes bloquean el consumo de la versión del paquete. Si la compilación de la aplicación depende de una versión actualizada a **Archivado**, la compilación fallará, a no ser que la versión del paquete se haya almacenado en la caché local. No puede usar un administrador de paquetes o una herramienta de compilación para volver a publicar una versión de un paquete **Archivado** porque todavía está presente en el repositorio. Sin embargo, puede cambiar el estado de la versión del paquete a **Sin enumerar** o **Publicada** en la consola.
+ **Eliminar**: la versión del paquete no aparece en las listas y los activos no se pueden descargar del repositorio. La diferencia clave entre **Dispuesto** y **Archivado** es que, con el estado **Dispuesto**, los activos de la versión del paquete se eliminan permanentemente. CodeCatalyst Por este motivo, no puede mover una versión de paquete de **Eliminar** a **Archivado**, **Sin enumerar** o **Publicada**. La versión del paquete no se puede utilizar porque se han eliminado los activos. Si una versión del paquete se ha marcado como **Eliminar**, ya no se le facturará el almacenamiento de los activos del paquete.
Además de los estados de la lista anterior, la versión de un paquete también se puede eliminar. Una vez eliminada, la versión de un paquete deja de estar en el repositorio y puede volver a publicarla libremente mediante un administrador de paquetes o una herramienta de compilación.
## Normalización del nombre del paquete, la versión del paquete y el nombre del activo
CodeCatalyst normaliza los nombres de los paquetes, las versiones de los paquetes y los nombres de los activos antes de almacenarlos, lo que significa que los nombres o las versiones CodeCatalyst pueden ser diferentes del nombre o la versión proporcionados cuando se publicó el paquete. Para obtener más información sobre cómo se normalizan los nombres y las versiones CodeCatalyst para cada tipo de paquete, consulte la siguiente documentación.
+ [Normalización de nombres de paquetes de Python](python-name-normalization.md)
+ [NuGet normalización del nombre del paquete, la versión y el nombre del activo](nuget-name-normalization.md)
CodeCatalyst no realiza la normalización en otros formatos de paquete.
# Edición de los controles de origen de los paquetes
En Amazon CodeCatalyst, las versiones de los paquetes se pueden añadir a un repositorio de paquetes publicándolas directamente, retirándolas de un repositorio anterior o incorporándolas desde un repositorio público externo a través de una puerta de enlace. Si permite que las versiones de un paquete se añadan mediante publicación directa e ingestión desde repositorios públicos, quedará en un estado de vulnerabilidad ante un ataque de sustitución de dependencias. Para obtener más información, consulte [Ataques de sustitución de dependencias](#dependency-substitution-attacks). Para protegerse de un ataque de sustitución de dependencias, configure los controles de origen de los paquetes de un repositorio para limitar la forma en que se pueden añadir las versiones de ese paquete al repositorio.
Debería valorar la posibilidad de configurar controles de orígenes de paquetes para que las nuevas versiones de diferentes paquetes vengan tanto de orígenes internos, como la publicación directa, como de externos, como los repositorios públicos. De forma predeterminada, los controles de origen de los paquetes se configurarán en función de cómo se añada la primera versión del paquete al repositorio.
## Configuración de los controles de origen del paquete
Con los controles de origen de los paquetes, puede configurar cómo se pueden añadir las versiones de los paquetes a un repositorio. Las siguientes listas incluyen la configuración y los valores de control de origen de los paquetes disponibles.
**Publish**
Esta configuración configura si las versiones de los paquetes se pueden publicar directamente en el repositorio mediante administradores de paquetes o herramientas similares.
+ **ALLOW**: las versiones de los paquetes se pueden publicar directamente.
+ **BLOCK**: las versiones de los paquetes no se pueden publicar directamente.
**Repositorios ascendentes**
Esta configuración configura si las versiones de los paquetes pueden ingerirse desde repositorios públicos externos o conservarse desde repositorios originales cuando lo solicite un administrador de paquetes.
+ **PERMITIR**: Se puede conservar cualquier versión de paquete de otros CodeCatalyst repositorios configurados como repositorios anteriores o bien se puede ingerir desde una fuente pública con una conexión externa.
+ **BLOCK**: Las versiones de los paquetes no se pueden conservar de otros CodeCatalyst repositorios configurados como repositorios ascendentes ni se pueden ingerir desde una fuente pública con una conexión externa.
### Configuración predeterminada de los controles de origen de los paquetes
Los controles de origen de los paquetes predeterminados se basarán en la forma en que se añada la primera versión de ese paquete al repositorio de paquetes.
+ Si un administrador de paquetes publica directamente la primera versión del paquete, la configuración será **Publish: ALLOW** y **Upstream: BLOCK**.
+ Si la primera versión del paquete proviene de una fuente pública, los ajustes serán **Publish: BLOCK** y **Upstream: BLOCK**.
## Escenarios comunes de control de acceso a paquetes
En esta sección se describen algunos escenarios comunes en los que se agrega una versión de paquete a un repositorio de paquetes. CodeCatalyst Los ajustes de control de origen del paquete se establecerán para los paquetes nuevos en función de cómo se añada la primera versión del paquete.
En los siguientes escenarios, un *paquete interno* se publica directamente desde un administrador de paquetes en el repositorio, como un paquete que usted mantenga. Un *paquete externo* es un paquete que existe en un repositorio público y que puede incorporarse al repositorio mediante una conexión ascendente a un repositorio de puerta de enlace.
**Se publica una versión de paquete externo para un paquete interno existente**
En este escenario, consideremos un paquete interno, *packageA*. Su equipo publica la primera versión del paquete del paquete A *en* un repositorio de CodeCatalyst paquetes. Como esta es la primera versión del paquete, la configuración del control de origen del paquete se establece automáticamente en **Publish: Allow** and **Upstream: Block**. Una vez publicado el paquete en tu repositorio, se publica un paquete con el mismo nombre en un repositorio público que está conectado a tu repositorio de CodeCatalyst paquetes. Podría tratarse de un intento de ataque de sustitución de dependencias contra el paquete interno o podría ser una coincidencia. En cualquier caso, los controles de origen de los paquetes están configurados para bloquear la ingesta de la nueva versión externa y protegerse así de un posible ataque.
En la siguiente imagen, *RePoA* es tu repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. `npm-public-registry-gateway` Su repositorio contiene las versiones 1.1 y 2.1 de *packageA*, pero la versión 3.0 está publicada en el repositorio público. Normalmente, *repoA* ingiere la versión 3.0 después de que un administrador de paquetes solicite el paquete. Como la ingesta de paquetes está configurada como **Bloquear**, la versión 3.0 no se ingiere en su repositorio de CodeCatalyst paquetes y no está disponible para los administradores de paquetes conectados a él.
![\[Gráfico sencillo que muestra el bloqueo de una nueva versión de un paquete externo en un repositorio público.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)
**Se publica una versión de paquete interno para un paquete externo existente**
En este escenario, un paquete, *packageB*, existe externamente en un repositorio público que usted ha conectado a su repositorio. Cuando un administrador de paquetes conectado a su repositorio solicita el *packageB*, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete de *packageB* que se agrega a su repositorio, los ajustes de origen del paquete están configurados como **Publish: BLOCK** y **Upstream: ALLOW**. Más adelante, intenta publicar una versión con el mismo nombre de paquete en el repositorio. Es posible que no conozca el paquete público y esté intentando publicar un paquete no relacionado con el mismo nombre, que esté intentando publicar una versión parcheada o que esté intentando publicar directamente la versión exacta del paquete que ya existe de forma externa. CodeCatalyst rechaza la versión que está intentando publicar, pero puede anular el rechazo de forma explícita y publicar la versión, si es necesario.
En la imagen siguiente, *RePoA* es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. `npm-public-registry-gateway` Su repositorio de paquetes contiene la versión 3.0 que ingirió del repositorio público. Quiere publicar la versión 1.2 en el repositorio de paquetes. Normalmente, podría publicar la versión 1.2 en *repoA*, pero como la publicación está configurada en **Block**, la versión 1.2 no se puede publicar.
![\[Gráfico simple que muestra la publicación de paquetes bloqueada.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)
**Publicar una versión parcheada de un paquete externo existente**
En este escenario, un paquete, *packageB*, existe externamente en un repositorio público que usted ha conectado al repositorio de paquetes. Cuando un administrador de paquetes conectado a su repositorio solicita el *packageB*, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete de *packageB* que se agrega a su repositorio, los ajustes de origen del paquete están configurados como **Publish: BLOCK** y **Upstream: ALLOW**. Su equipo decide publicar las versiones de los paquetes parcheados de este paquete en el repositorio. Para poder publicar las versiones de los paquetes directamente, su equipo cambia la configuración del control de origen de los paquetes a **Publish: ALLOW** y **Upstream: BLOCK**. Las versiones de este paquete ahora se pueden publicar directamente en su repositorio e ingerir desde los repositorios públicos. Una vez que su equipo publique las versiones de los paquetes parcheados, cambiará la configuración de origen del paquete a **Publish: BLOCK** and **Upstream: ALLOW**.
## Edición de los controles de origen de los paquetes
Los controles de origen de los paquetes se configuran automáticamente en función de cómo se añade la primera versión del paquete al repositorio de paquetes. Para obtener más información, consulte [Configuración predeterminada de los controles de origen de los paquetes](#default-package-origin-control-settings). Para añadir o editar los controles de origen de un paquete en un repositorio de CodeCatalyst paquetes, lleve a cabo los pasos del siguiente procedimiento.
**Adición o edición de los controles de origen del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. Elija el repositorio de paquetes que contenga el paquete que desea editar.
1. En la tabla **Paquetes**, busque y seleccione el paquete que desee editar.
1. En la página de resumen del paquete, seleccione **Controles de origen**.
1. En **Controles de origen**, seleccione los controles de origen del paquete que desee configurar para este paquete. Los dos ajustes de control de origen del paquete (**Publicar** y **Ascendente**) deben configurarse al mismo tiempo.
+ Para permitir la publicación directa de las versiones de los paquetes, en **Publicar**, seleccione **Permitir**. Para bloquear la publicación de versiones de paquetes, seleccione **Bloquear**.
+ Para permitir la ingesta de paquetes de repositorios externos y la extracción de paquetes de repositorios anteriores, en **Recursos ascendentes**, seleccione **Permitir**. Para bloquear la ingesta y la extracción de versiones de paquetes desde repositorios externos y ascendentes, seleccione **Bloquear.**
1. Seleccione **Save**.
## Repositorios editoriales y originales
En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm `lodash@1.0` en un repositorio (`myrepo`), y que `myrepo` tiene un repositorio ascendente con una conexión externa a npmjs.com. Considere los siguientes escenarios.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: ALLOW y **Upstream: ALLOW****. Si `lodash@1.0` está presente en el repositorio original o en npmjs.com, CodeCatalyst rechaza cualquier intento de publicación en él emitiendo un error 409 de conflicto. `myrepo` Aún puede publicar una versión diferente, por ejemplo `lodash@1.1`.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: ALLOW y **Upstream: BLOCK****. Puede publicar en su repositorio cualquier versión de `lodash` que aún no exista, porque no se puede acceder a las versiones de los paquetes.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: BLOCK** y **Upstream: ALLOW**. No puede publicar ninguna versión del paquete directamente en su repositorio.
## Ataques de sustitución de dependencias
Los administradores de paquetes simplifican el proceso de empaquetar y compartir código reutilizable. Estos paquetes pueden ser paquetes privados desarrollados por una organización para usarlos en sus aplicaciones, o pueden ser públicos, generalmente paquetes de código abierto que se desarrollan fuera de una organización y se distribuyen en repositorios de paquetes públicos. Al solicitar paquetes, los desarrolladores confían en su administrador de paquetes para obtener nuevas versiones de sus dependencias. Los ataques de sustitución de dependencias, también conocidos como ataques de confusión de dependencias, aprovechan el hecho de que un administrador de paquetes normalmente no tiene forma de distinguir las versiones legítimas de un paquete de las versiones maliciosas.
Los ataques de sustitución de dependencias pertenecen a un subconjunto de ataques conocidos como ataques a la cadena de suministro de software. Un ataque a la cadena de suministro de software es un ataque que aprovecha las vulnerabilidades en cualquier punto de la cadena de suministro de software.
Un ataque de sustitución de dependencias puede dirigirse a cualquier persona que utilice tanto paquetes desarrollados internamente como paquetes extraídos de repositorios públicos. Los atacantes identifican los nombres de los paquetes internos y, a continuación, colocan estratégicamente el código malicioso con el mismo nombre en los repositorios de paquetes públicos. Normalmente, el código malicioso se publica en un paquete con un número de versión alto. Los administradores de paquetes obtienen el código malicioso de estas fuentes públicas porque creen que los paquetes maliciosos son las últimas versiones del paquete. Esto provoca una confusión o una sustitución entre el paquete deseado y el paquete malicioso, lo que hace que el código quede comprometido.
Para evitar los ataques de sustitución de dependencias, Amazon CodeCatalyst proporciona controles de origen de los paquetes. Los controles de origen de los paquetes son ajustes que controlan cómo se pueden añadir los paquetes a los repositorios. Los controles se configuran automáticamente cuando se añade la primera versión de un paquete nuevo a un CodeCatalyst repositorio. Los controles pueden garantizar que las versiones de los paquetes no puedan publicarse directamente en su repositorio ni ingerirse desde fuentes públicas, lo que le protege de los ataques de sustitución de dependencias. Para obtener más información sobre los controles de origen de los paquetes y cómo cambiarlos, consulte [Edición de los controles de origen de los paquetes](#package-origin-controls).
# Con npm
En estos temas se describe cómo puede utilizar `npm` el administrador de paquetes Node.js con CodeCatalyst.
**nota**
CodeCatalyst admite `node v4.9.1` y versiones posteriores `npm v5.0.0` y posteriores.
**Topics**
+ [Configuración y uso de npm](packages-npm-use.md)
+ [control de etiquetas npm](packages-npm-tags.md)
# Configuración y uso de npm
Para usarlo `npm` con CodeCatalyst, debe conectarse `npm` a su repositorio de paquetes y proporcionar un token de acceso personal (PAT) para la autenticación. Puedes ver las instrucciones para conectarte `npm` al repositorio de paquetes en la CodeCatalyst consola.
**Contents**
+ [Configurar npm con CodeCatalyst](#npm-configure)
+ [Instalación de paquetes npm desde un repositorio de paquetes CodeCatalyst](#npm-install)
+ [Instalación de paquetes npm desde npmjs mediante CodeCatalyst](#npm-install-npmjs)
+ [Publicar paquetes npm en tu repositorio de paquetes CodeCatalyst](#npm-publish)
+ [soporte de comandos npm](#npm-commands)
+ [Comandos compatibles que interactúan con un repositorio de paquetes](#supported-commands-that-interact-with-a-repository)
+ [Comandos del lado del cliente compatibles](#supported-client-side-commands)
+ [Comandos admitidos](#unsupported-commands)
## Configurar npm con CodeCatalyst
Las siguientes instrucciones explican cómo autenticarse y conectarse `npm` a su repositorio de CodeCatalyst paquetes. Para obtener más información sobre npm, consulte la [documentación oficial de npm](https://docs.npmjs.com/).
**Para conectarse `npm` a su repositorio de CodeCatalyst paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Vaya a su proyecto.
1. En el panel de navegación, elija **Paquetes**.
1. Seleccione el repositorio de paquetes de la lista.
1. Seleccione **Establecer conexión con el repositorio**.
1. En **Detalles de configuración**, en **Cliente administrador de paquetes**, seleccione **cliente npm**.
1. Seleccione su sistema operativo para ver los pasos de configuración correspondientes.
1. Se necesita un token de acceso personal (PAT) para autenticar npm. CodeCatalyst Si ya tiene un token, puede usarlo. Si no es así, puede crear uno mediante los siguientes pasos.
1. **(Opcional):** actualice el **Nombre de PAT** y la **Fecha de vencimiento**.
1. Seleccione **Crear token**.
1. Copie y almacene el PAT en un lugar seguro.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT. Las credenciales deben ser de corta duración para minimizar el tiempo durante el que un atacante puede utilizarlas tras apropiarse indebidamente de ellas.
1. Ejecute los siguientes comandos desde el directorio raíz del proyecto para configurar npm con su repositorio de paquetes. Los comandos harán lo siguiente:
+ Crear un archivo `.npmrc` en el nivel de proyecto (si el proyecto no tiene uno).
+ Añadir información de punto de conexión del repositorio de paquetes al archivo `.npmrc` en el nivel de proyecto.
+ Añadir sus credenciales (PAT) al archivo `.npmrc` en el nivel de usuario.
Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, debe actualizar los valores de los siguientes comandos; luego, no será necesario cambiarlos.
+ *username*Sustitúyalo por tu nombre CodeCatalyst de usuario.
+ *PAT*Sustitúyalo por tu CodeCatalyst PAT.
+ Reemplácelo por *space\$1name* CodeCatalyst el nombre de su espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
npm set registry=https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/ --location project
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:_authToken=username:PAT
```
**Para npm 6 o versiones anteriores:** para que npm siempre pase el token de autenticación CodeCatalyst, incluso para las `GET` solicitudes, defina la variable de configuración always-auth de la siguiente manera. `npm config set`
```
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:always-auth=true --location project
```
## Instalación de paquetes npm desde un repositorio de paquetes CodeCatalyst
Después de conectar npm a su repositorio siguiendo los pasos indicados en [Configurar npm con CodeCatalyst](#npm-configure), puede ejecutar comandos `npm` en su repositorio.
Puede instalar un paquete npm que esté en su repositorio de CodeCatalyst paquetes o en uno de sus repositorios anteriores con el comando. `npm install`
```
npm install lodash
```
## Instalación de paquetes npm desde npmjs mediante CodeCatalyst
Puede instalar paquetes npm desde [npmjs.com](https://www.npmjs.com/) a través de un repositorio configurándolo con una conexión ascendente al CodeCatalyst repositorio de puerta de enlace conectado a npmjs.com,. **npm-public-registry-gateway** Los paquetes instalados desde npmjs se ingieren y almacenan en el repositorio de puerta de enlace y en el repositorio de paquetes descendentes más alejado.
**Instalación de paquetes desde npmjs**
1. Si aún no lo ha hecho, configúrelo `npm` con su CodeCatalyst repositorio de paquetes siguiendo los pasos que se indican en. [Configurar npm con CodeCatalyst](#npm-configure)
1. Comprueba que tu repositorio haya agregado el repositorio de puerta de enlace **npm-public-registry-gateway**,, como conexión ascendente. Puede comprobar qué fuentes ascendentes se añaden o añadir **npm-public-registry-gateway**como fuente ascendente siguiendo las instrucciones que aparecen en el repositorio [Adición de un repositorio ascendente](packages-upstream-repositories-add.md) y seleccionándolo. **npm-public-registry-gateway**
1. Instale los paquetes con el comando `npm install`.
```
npm install package_name
```
Para obtener más información sobre cómo solicitar paquetes desde repositorios ascendentes, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
## Publicar paquetes npm en tu repositorio de paquetes CodeCatalyst
Cuando haya terminado [Configurar npm con CodeCatalyst](#npm-configure), puede ejecutar los comandos `npm`.
Puede publicar un paquete npm en un repositorio de CodeCatalyst paquetes con el `npm publish` comando.
```
npm publish
```
Para obtener información sobre cómo crear paquetes npm, consulte [Creating Node.js Modules](https://docs.npmjs.com/getting-started/creating-node-modules) en *npm Docs*.
## soporte de comandos npm
En las siguientes secciones se resumen los `npm` comandos que admiten los repositorios de CodeCatalyst paquetes, además de enumerar los comandos específicos que no son compatibles.
**Topics**
+ [Comandos compatibles que interactúan con un repositorio de paquetes](#supported-commands-that-interact-with-a-repository)
+ [Comandos del lado del cliente compatibles](#supported-client-side-commands)
+ [Comandos admitidos](#unsupported-commands)
### Comandos compatibles que interactúan con un repositorio de paquetes
En esta sección, se enumeran los comandos `npm` en los que el cliente de `npm` realiza una o más solicitudes al registro con el que se ha configurado (por ejemplo, `npm config set registry`). Se ha comprobado que estos comandos funcionan correctamente cuando se invocan en un repositorio de CodeCatalyst paquetes.
****
| Comando | Description (Descripción) |
| --- | --- |
| [errores](https://docs.npmjs.com/cli/bugs) | Intenta adivinar la ubicación de la URL del rastreador de errores de un paquete y trata de abrirla. |
| [ci](https://docs.npmjs.com/cli/ci) | Instala un proyecto desde cero. |
| [deprecate](https://docs.npmjs.com/cli/deprecate) | Deja en desuso una versión de un paquete. |
| [dist-tag](https://docs.npmjs.com/cli/dist-tag) | Modifica las etiquetas de distribución de paquetes. |
| [docs](https://docs.npmjs.com/cli/docs) | Intenta adivinar la ubicación de la URL de la documentación de un paquete y trata de abrirla mediante el parámetro de configuración `--browser`. |
| [doctor](https://docs.npmjs.com/cli/doctor) | Ejecuta un conjunto de comprobaciones para validar que su instalación de npm pueda administrar sus JavaScript paquetes. |
| [install](https://docs.npmjs.com/cli/install) | Instala un paquete. |
| [install-ci-test](https://docs.npmjs.com/cli/install-ci-test) | Instala un proyecto desde cero y ejecuta pruebas. Alias: `npm cit`. Este comando ejecuta un `npm ci` seguido inmediatamente por un `npm test`. |
| [install-test](https://docs.npmjs.com/cli/install-test) | Instala el paquete y ejecuta las pruebas. Ejecuta un `npm install` seguido inmediatamente por un `npm test`. |
| [outdated](https://docs.npmjs.com/cli/outdated) | Comprueba el registro configurado para ver si alguno de los paquetes instalados está desactualizado. |
| [ping](https://docs.npmjs.com/cli/ping) | Hace ping al registro npm configurado o dado y verifica la autenticación. |
| [publish](https://docs.npmjs.com/cli/publish) | Publica una versión del paquete en el registro. |
| [update](https://docs.npmjs.com/cli/update) | Intenta adivinar la ubicación de la URL del repositorio de un paquete y trata de abrirla mediante el parámetro de configuración `--browser`. |
| [view](https://docs.npmjs.com/cli/view) | Muestra metadatos del paquete. También se puede usar para imprimir las propiedades de los metadatos. |
### Comandos del lado del cliente compatibles
Estos comandos no requieren ninguna interacción directa con un repositorio de paquetes, por lo que CodeCatalyst no requieren nada que los respalde.
****
| Comando | Description (Descripción) |
| --- | --- |
| [bin (heredado)](https://docs.npmjs.com/cli/v8/commands/npm-bin) | Muestra el directorio `bin` de npm. |
| [build](https://docs.npmjs.com/cli/v6/commands/npm-build) | Crea un paquete. |
| [cache](https://docs.npmjs.com/cli/cache) | Manipula la caché de paquetes. |
| [completion](https://docs.npmjs.com/cli/completion) | Permite completar tabulaciones en todos los comandos de npm. |
| [config](https://docs.npmjs.com/cli/config) | Actualiza el contenido de los archivos `npmrc` globales y de usuario. |
| [dedupe](https://docs.npmjs.com/cli/dedupe) | Busca en el árbol de paquetes local e intenta simplificar la estructura moviendo las dependencias más arriba en el árbol, donde pueden compartirse de manera más eficaz entre varios paquetes dependientes. |
| [edit](https://docs.npmjs.com/cli/edit) | Edita un paquete instalado. Selecciona una dependencia en el directorio de trabajo actual y abre el directorio del paquete en el editor predeterminado. |
| [explore](https://docs.npmjs.com/cli/explore) | Busca un paquete instalado. Genera una subshell en el directorio del paquete instalado especificado. Si se especifica un comando, se ejecuta en la subshell, que finaliza inmediatamente. |
| [help](https://docs.npmjs.com/cli/help) | Obtiene ayuda sobre npm. |
| [help-search](https://docs.npmjs.com/cli/help-search) | Busca en la documentación de ayuda de npm. |
| [init](https://docs.npmjs.com/cli/init) | Crea un archivo `package.json`. |
| [link](https://docs.npmjs.com/cli/link) | Enlaza simbólicamente un directorio de paquetes. |
| [ls](https://docs.npmjs.com/cli/ls) | Muestra los paquetes instalados. |
| [pack](https://docs.npmjs.com/cli/pack) | Crea un tarball a partir de un paquete. |
| [prefix](https://docs.npmjs.com/cli/prefix) | Muestra un prefijo. Este es el directorio principal más cercano que contiene un archivo `package.json`, a menos que también se especifique `-g`. |
| [prune](https://docs.npmjs.com/cli/prune) | Elimina los paquetes que no figuran en la lista de dependencias del paquete principal. |
| [rebuild](https://docs.npmjs.com/cli/rebuild) | Ejecuta el comando `npm build` en las carpetas coincidentes. |
| [restart](https://docs.npmjs.com/cli/restart) | Ejecuta los scripts de parada, reinicio e inicio de un paquete, así como los scripts previos y posteriores asociados. |
| [root](https://docs.npmjs.com/cli/root) | Imprime el directorio `node_modules` efectivo en formato estándar. |
| [run-script](https://docs.npmjs.com/cli/run-script) | Ejecuta scripts de paquetes arbitrarios. |
| [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) | Bloquea las versiones dependientes para su publicación. |
| [uninstall](https://docs.npmjs.com/cli/uninstall) | Desinsta un paquete. |
### Comandos admitidos
Estos `npm` comandos no son compatibles con los repositorios de CodeCatalyst paquetes.
****
| Comando | Description (Descripción) | Notas |
| --- | --- | --- |
| [access](https://docs.npmjs.com/cli/access) | Establece el nivel de acceso de los paquetes publicados. | CodeCatalyst usa un modelo de permisos diferente al del repositorio público de npmjs. |
| [adduser](https://docs.npmjs.com/cli/adduser) | Añade una cuenta de usuario de registro | CodeCatalyst utiliza un modelo de usuario diferente del repositorio público de npmjs. |
| [audit](https://docs.npmjs.com/cli/audit) | Realiza una auditoría de seguridad. | CodeCatalyst actualmente no vende datos sobre vulnerabilidades de seguridad. |
| [hook](https://docs.npmjs.com/cli/v9/commands/npm-hook) | Administra los enlaces npm, lo que incluye agregar, eliminar, enumerar y actualizar. | CodeCatalyst actualmente no admite ningún mecanismo de notificación de cambios. |
| [login](https://docs.npmjs.com/cli-commands/adduser.html) | Autentica a un usuario. Este es un alias para `npm adduser`. | CodeCatalyst utiliza un modelo de autenticación diferente del repositorio público de npmjs. Para obtener información, consulte [Configurar npm con CodeCatalyst](#npm-configure). |
| [logout](https://docs.npmjs.com/cli/logout) | Cierra la sesión del registro. | CodeCatalyst utiliza un modelo de autenticación diferente del repositorio público de npmjs. No hay forma de cerrar sesión en un CodeCatalyst repositorio, pero los tokens de autenticación caducan una vez transcurrido el tiempo de caducidad configurable. La duración predeterminada del token es de 12 horas. |
| [owner](https://docs.npmjs.com/cli/owner) | Administra a los propietarios de los paquetes. | CodeCatalyst utiliza un modelo de permisos diferente al del repositorio público de npmjs. |
| [profile](https://docs.npmjs.com/cli/profile) | Cambia la configuración de su perfil de registro. | CodeCatalyst utiliza un modelo de usuario diferente del repositorio público de npmjs. |
| [search](https://docs.npmjs.com/cli/search) | Busca en el registro paquetes que coincidan con los términos de búsqueda. | CodeCatalyst no admite el `search` comando. |
| [star](https://docs.npmjs.com/cli/star) | Marca sus paquetes favoritos. | CodeCatalyst actualmente no admite ningún mecanismo de favoritos. |
| [stars](https://docs.npmjs.com/cli/stars) | Visualiza los paquetes marcados como favoritos. | CodeCatalyst actualmente no admite ningún mecanismo de favoritos. |
| [team](https://docs.npmjs.com/cli/team) | Administra los equipos y las pertenencias a estos. | CodeCatalyst utiliza un modelo de membresía de usuarios y grupos diferente del repositorio público de npmjs. |
| [token](https://docs.npmjs.com/cli/token) | Administra sus tokens de autenticación. | CodeCatalyst utiliza un modelo diferente para obtener los tokens de autenticación. Para obtener información, consulte [Configurar npm con CodeCatalyst](#npm-configure). |
| [unpublish](https://docs.npmjs.com/cli/unpublish) | Elimina un paquete del registro. | CodeCatalyst no admite la eliminación de una versión de paquete de un repositorio mediante el cliente npm. Puede eliminar un paquete en la consola. |
| [whoami](https://docs.npmjs.com/cli/whoami) | Muestra el nombre de usuario de npm. | CodeCatalyst usa un modelo de usuario diferente del repositorio público de npmjs. |
# control de etiquetas npm
Los registros npm admiten *etiquetas*, que son alias de cadena para las versiones de los paquetes. Puede usar etiquetas para proporcionar un alias en lugar de números de versión. Por ejemplo, puede tener un proyecto con varios flujos de desarrollo y usar una etiqueta diferente para cada flujo (como `stable`, `beta`, `dev` o `canary`). Para obtener más información, consulte [dist-tag](https://docs.npmjs.com/cli/dist-tag) en *npm Docs*.
De forma predeterminada, npm usa la etiqueta `latest` para identificar la versión actual de un paquete. `npm install pkg`(sin especificador `@version` `@tag`) instala la última etiqueta. Por lo general, los proyectos solo utilizan la etiqueta más reciente para las versiones estables. Se utilizan otras etiquetas para las versiones inestables o preliminares.
## Edición de etiquetas con el cliente npm
Los tres `npm dist-tag` comandos (`add``rm`, y`ls`) funcionan de la misma manera en los repositorios de CodeCatalyst paquetes que en el registro [npm predeterminado](https://registry.npmjs.com/).
## Etiquetas npm y repositorios ascendentes
Cuando `npm` solicita las etiquetas de un paquete y las versiones de ese paquete también están presentes en un repositorio principal, CodeCatalyst fusiona las etiquetas antes de devolverlas al cliente. Por ejemplo, un repositorio denominado `R` tiene un repositorio ascendente denominado `U`. En la siguiente tabla, se muestran las etiquetas de un paquete denominado `web-helper`, que se encuentra en ambos repositorios.
****
| Repository | Nombre del paquete | Etiquetas del paquete |
| --- | --- | --- |
| R | `web-helper` | *latest* (alias de la versión 1.0.0) |
| U | `web-helper` | *alpha* (alias de la versión 1.0.1) |
En este caso, cuando el cliente npm obtiene las etiquetas del paquete `web-helper` del repositorio `R`, recibe las etiquetas *latest* y *alpha*. Las versiones a las que apuntan las etiquetas no cambiarán.
*Cuando la misma etiqueta está presente en el mismo paquete, tanto en el repositorio original como en el local, CodeCatalyst utiliza la etiqueta que se actualizó por última vez.* Por ejemplo, supongamos que las etiquetas de *webhelper* se han modificado para que tengan el siguiente aspecto.
****
| Repository | Nombre del paquete | Etiquetas del paquete | Última actualización |
| --- | --- | --- | --- |
| R | `web-helper` | *latest* (alias de la versión 1.0.0) | 1 de enero de 2023 |
| U | `web-helper` | *latest* (alias de la versión 1.0.1) | 1 de junio de 2023 |
En este caso, cuando el cliente npm obtenga las etiquetas del paquete *web-helper* del repositorio `R`, la etiqueta *latest* usará el alias de la versión *1.0.1* porque es la última que se ha actualizado. Esto facilita el consumo de nuevas versiones de paquetes en un repositorio ascendente que aún no se encuentren en un repositorio local ejecutando `npm update`.
# Uso de Maven
El formato de repositorio Maven lo utilizan muchos lenguajes diferentes, incluidos Java, Kotlin, Scala y Clojure. Es compatible con muchas herramientas de compilación diferentes, como Maven, Gradle, Scala SBT, Apache Ivy y Leiningen.
Hemos probado y confirmado la compatibilidad con CodeCatalyst las siguientes versiones:
+ Última versión de **Maven**: 3.6.3.
+ Versión más reciente de **Gradle**: 6.4.1. También se ha probado la versión 5.5.1.
**Topics**
+ [Configuración y uso de Gradle Groovy](packages-maven-gradle.md)
+ [Configuración y uso de mvn](packages-maven-mvn.md)
+ [Publicación de paquetes con curl](packages-maven-curl.md)
+ [Uso de sumas de comprobación e instantáneas de Maven](packages-maven-checksums-snapshots.md)
# Configuración y uso de Gradle Groovy
Para usar Gradle Groovy con CodeCatalyst, debes conectar Gradle Groovy a tu repositorio de paquetes y proporcionar un token de acceso personal (PAT) para la autenticación. Puedes ver las instrucciones para conectar Gradle Groovy a tu repositorio de paquetes en la consola. CodeCatalyst
**Contents**
+ [Obteniendo dependencias de CodeCatalyst](#gradle-fetch-dependencies)
+ [Obteniendo complementos de CodeCatalyst](#gradle-fetch-plugins)
+ [Obtención de paquetes de repositorios de paquetes externos mediante CodeCatalyst](#gradle-install-public)
+ [Publicar paquetes en CodeCatalyst](#gradle-publish-packages)
+ [Ejecución de una compilación de Gradle en IntelliJ IDEA](#gradle-intellij)
+ [Método 1: colocar el PAT en `gradle.properties`](#gradle-intellij-gradle-properties)
+ [Método 2: colocar el PAT en un archivo independiente](#gradle-intellij-file)
## Obteniendo dependencias de CodeCatalyst
En las siguientes instrucciones, se explica cómo configurar Gradle Groovy para que busque las dependencias en el repositorio de paquetes. CodeCatalyst
**Para usar Gradle Groovy para recuperar las dependencias del repositorio de paquetes CodeCatalyst**
1. [Abre la consola en https://codecatalyst.aws/. CodeCatalyst ](https://codecatalyst.aws/)
1. Vaya a su proyecto.
1. En el panel de navegación, elija **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, seleccione **Gradle Groovy** en la lista de clientes de administrador de paquetes.
1. Necesitarás un token de acceso personal (PAT) para autenticar a Gradle Groovy. CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Actualice el archivo de propiedades de Gradle con sus credenciales de acceso. *username*Sustitúyelo por su CodeCatalyst nombre de usuario y sustitúyalo por su *PAT* token de acceso personal. CodeCatalyst Puedes usar cualquier valor durante *spaceUsername* y *spacePassword* siempre que utilices los mismos valores en los siguientes pasos.
```
spaceUsername=username
spacePassword=PAT
```
1. Para obtener las dependencias de una compilación CodeCatalyst de Gradle, copia el fragmento de `maven` código y agrégalo a la `repositories` sección del archivo de tu proyecto. `build.gradle` Reemplace los siguientes valores. Puedes usar cualquier valor siempre y *spaceName* cuando utilices los mismos valores en los siguientes pasos.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *space\$1name*Sustitúyalo por CodeCatalyst el nombre del espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
```
1. (Opcional) Para usar el repositorio de CodeCatalyst paquetes como la única fuente para las dependencias de su proyecto, elimine del archivo cualquier otra sección de los `build.gradle` repositorios. Si tiene más de un repositorio, Gradle busca las dependencias en cada repositorio en el orden en que aparecen en la lista.
## Obteniendo complementos de CodeCatalyst
De forma predeterminada, Gradle resolverá los complementos desde el [portal de complementos de Gradle](https://plugins.gradle.org/) público. Los siguientes pasos configuran tu proyecto de Gradle para resolver los complementos del repositorio de CodeCatalyst paquetes.
**Para usar Gradle para buscar complementos de tu repositorio de paquetes CodeCatalyst**
1. [Abre la CodeCatalyst consola en https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Vaya a su proyecto.
1. En el panel de navegación, elija **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, seleccione **Gradle** en la lista de clientes del administrador de paquetes.
1. Necesitarás un token de acceso personal (PAT) para autenticar a Gradle. CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Actualice el archivo de propiedades de Gradle con sus credenciales de acceso. *username*Sustitúyelo por su CodeCatalyst nombre de usuario y *PAT* sustitúyalo por su token de acceso CodeCatalyst personal. Puedes usar cualquier valor durante *spaceUsername* y *spacePassword* siempre que utilices los mismos valores en los siguientes pasos.
```
spaceUsername=username
spacePassword=PAT
```
1. Agregue un bloque `pluginManagement` a su archivo `settings.gradle`. El bloque `pluginManagement` debe aparecer antes de cualquier otra declaración en `settings.gradle`. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *spaceName*Sustitúyalo por el valor del nombre utilizado en el paso anterior.
+ *space\$1name*Sustitúyalo por CodeCatalyst el nombre de tu espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
pluginManagement {
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
Esto garantizará que Gradle resuelva los complementos del repositorio especificado. El repositorio debe tener una conexión ascendente configurada con el portal de complementos de Gradle (`gradle-plugins-store`) para que los complementos de Gradle que se requieren con más frecuencia estén disponibles en la compilación. Para obtener más información, consulte la [documentación de Gradle](https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories).
## Obtención de paquetes de repositorios de paquetes externos mediante CodeCatalyst
Puede instalar paquetes Maven desde repositorios públicos a través de un CodeCatalyst repositorio configurándolo con una conexión ascendente a la puerta de enlace que representa el repositorio de la puerta de enlace. Los paquetes instalados desde el repositorio de la puerta de enlace se ingieren y almacenan en su repositorio. CodeCatalyst
CodeCatalyst admite los siguientes repositorios públicos de paquetes de Maven.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway
**Instalación de paquetes desde repositorios públicos de paquetes de Maven**
1. Si aún no lo has hecho, configura Gradle con tu repositorio de CodeCatalyst paquetes siguiendo los pasos que se indican en o. [Obteniendo dependencias de CodeCatalyst](#gradle-fetch-dependencies) [Obteniendo complementos de CodeCatalyst](#gradle-fetch-plugins)
1. Compruebe que su repositorio haya añadido el repositorio de puerta de enlace desde el que desea hacer la instalación como conexión ascendente. Para ello, siga las instrucciones en [Adición de un repositorio ascendente](packages-upstream-repositories-add.md) y seleccione el repositorio de paquetes público que quiera añadir como ascendente.
Para obtener más información sobre cómo solicitar paquetes desde repositorios ascendentes, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
## Publicar paquetes en CodeCatalyst
En esta sección, se describe cómo publicar una biblioteca Java creada con Gradle Groovy en un repositorio. CodeCatalyst
**Para usar Gradle Groovy para publicar paquetes en un repositorio de paquetes CodeCatalyst**
1. [Abre la CodeCatalyst consola en https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, seleccione **Gradle Groovy** en la lista de clientes de administrador de paquetes.
1. Necesitarás un token de acceso personal (PAT) para autenticar a Gradle. CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Actualice el archivo de propiedades de Gradle con sus credenciales de acceso. *username*Sustitúyelo por su CodeCatalyst nombre de usuario y *PAT* sustitúyalo por su token de acceso CodeCatalyst personal. Puedes usar cualquier valor durante *spaceUsername* y *spacePassword* siempre que utilices los mismos valores en los siguientes pasos.
```
spaceUsername=username
spacePassword=PAT
```
1. Primero, añada el complemento `maven-publish` a la sección `plugins` del archivo `build.gradle` del proyecto.
```
plugins {
id 'java-library'
id 'maven-publish'
}
```
1. A continuación, añada una sección `publishing` al archivo `build.gradle` del proyecto. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *space\$1name*Sustitúyalo por CodeCatalyst el nombre del espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'group-id'
artifactId = 'artifact-id'
version = 'version'
from components.java
}
}
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
El complemento `maven-publish` genera un archivo POM basado en los valores `groupId`, `artifactId` y `version` especificados en la sección `publishing`.
1. Una vez completados estos cambios en `build.gradle`, ejecute el siguiente comando para crear el proyecto y subirlo al repositorio.
```
./gradlew publish
```
1. Navegue hasta el repositorio de paquetes en la CodeCatalyst consola para comprobar que el paquete se publicó correctamente. Debería ver el paquete en la lista **Paquetes** del repositorio de paquetes.
Para obtener más información, consulte estos temas en el sitio web de Gradle:
+ [Building Java Libraries](https://guides.gradle.org/building-java-libraries/)
+ [Publishing a project as a module](https://docs.gradle.org/current/userguide/publishing_setup.html)
## Ejecución de una compilación de Gradle en IntelliJ IDEA
Puede ejecutar una compilación de Gradle en IntelliJ IDEA que extraiga dependencias de. CodeCatalyst Para autenticar a Gradle CodeCatalyst, debes usar un token de acceso personal (PAT). Puedes almacenar tu CodeCatalyst PAT en un archivo independiente `gradle.properties` o en otro que elijas.
### Método 1: colocar el PAT en `gradle.properties`
Use este método si no está utilizando el archivo `gradle.properties` y puede sobrescribir el contenido con el PAT. Si está utilizando `gradle.properties`, puede modificar este método para añadir el PAT en lugar de sobrescribir el contenido del archivo.
**nota**
El ejemplo muestra el archivo `gradle.properties` ubicado en `GRADLE_USER_HOME`.
En primer lugar, cree un PAT si no tiene uno.
**Creación de un token de acceso personal (PAT)**
1. En la barra de menú superior, elija su insignia de perfil y, a continuación, elija **Mi configuración**.
**sugerencia**
También puede encontrar su perfil de usuario en la página de miembros de un proyecto o espacio, seleccionando el nombre en la lista de miembros.
1. En **Nombre de PAT**, introduzca un nombre descriptivo para el PAT.
1. En **Fecha de vencimiento**, mantenga la fecha predeterminada o elija el icono del calendario para seleccionar una fecha personalizada. La fecha de vencimiento predeterminada es de 1 año a partir de la fecha actual.
1. Seleccione **Crear**.
También puede crear este token si elige **Clonar repositorio** para un repositorio de código fuente.
1. Guarde el secreto del PAT en un lugar seguro.
**importante**
El secreto del PAT solo se muestra una vez. No podrá recuperarlo después de cerrar la ventana.
A continuación, actualice el archivo `build.gradle` con el siguiente fragmento:
```
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
```
### Método 2: colocar el PAT en un archivo independiente
Utilice este método si no desea modificar el archivo `gradle.properties`.
En primer lugar, cree un PAT si no tiene uno.
**Creación de un token de acceso personal (PAT)**
1. En la barra de menú superior, elija su insignia de perfil y, a continuación, elija **Mi configuración**.
**sugerencia**
También puede encontrar su perfil de usuario en la página de miembros de un proyecto o espacio, seleccionando el nombre en la lista de miembros.
1. En **Nombre de PAT**, introduzca un nombre descriptivo para el PAT.
1. En **Fecha de vencimiento**, mantenga la fecha predeterminada o elija el icono del calendario para seleccionar una fecha personalizada. La fecha de vencimiento predeterminada es de 1 año a partir de la fecha actual.
1. Seleccione **Crear**.
También puede crear este token si elige **Clonar repositorio** para un repositorio de código fuente.
1. Guarde el secreto del PAT en un lugar seguro.
**importante**
El secreto del PAT solo se muestra una vez. No podrá recuperarlo después de cerrar la ventana.
**Colocación del PAT en un archivo independiente**
1. Actualice el archivo `build.gradle` con el siguiente fragmento: Sustituya *space\$1name* y *repo\$1name* por su nombre CodeCatalyst de usuario, nombre del espacio, nombre del proyecto y nombre del repositorio de paquetes. *proj\$1name*
```
def props = new Properties()
file("fileName").withInputStream { props.load(it) }
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
1. Escriba el PAT en el archivo especificado en su archivo `build.gradle`:
```
echo "codecatalystArtifactsToken=PAT" > fileName
```
# Configuración y uso de mvn
Para ejecutar las compilaciones de Maven, se utiliza el comando `mvn`. Debe configurar `mvn` para usar el repositorio de paquetes y proporcionar un token de acceso personal (PAT) para la autenticación.
**Contents**
+ [Obteniendo dependencias de CodeCatalyst](#mvn-fetch-dependencies)
+ [Obtención de paquetes de repositorios de paquetes externos mediante CodeCatalyst](#mvn-install-public)
+ [Publicar paquetes en CodeCatalyst](#mvn-publish-packages)
+ [Publicación de paquetes externos](#publishing-third-party-packages)
## Obteniendo dependencias de CodeCatalyst
`mvn`Para configurar la búsqueda de dependencias de un CodeCatalyst repositorio, debe editar el archivo de configuración de Maven `settings.xml` y, si lo desea, el archivo de objetos del modelo de proyecto (POM) del proyecto. El archivo POM contiene información sobre el proyecto, así como datos de configuración para que Maven compile el proyecto, como las dependencias, el directorio de compilación, el directorio del código fuente, el directorio del código fuente de pruebas, el complemento y los objetivos.
**Para usarlo para recuperar `mvn` las dependencias del repositorio de paquetes CodeCatalyst**
1. [Abre la CodeCatalyst consola en https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, elija **mvn** en la lista de clientes de administrador de paquetes.
1. Necesitará un token de acceso personal (PAT) para `mvn` autenticarse CodeCatalyst. Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Añada al archivo `settings.xml` un perfil que contenga su repositorio. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *space\$1name*Sustitúyalo por CodeCatalyst el nombre de tu espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
repo_name
true
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
```
1. Añada su servidor a la lista de servidores en el archivo `settings.xml`. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
+ *username*Sustitúyalo por tu nombre CodeCatalyst de usuario.
+ *PAT*Sustitúyalo por tu CodeCatalyst PAT.
```
repo_name
username
PAT
```
1. (Opcional) Configure un espejo en el archivo `settings.xml` que capture todas las conexiones y las dirija a su repositorio, en lugar de dirigirlas a un repositorio de puerta de enlace.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *space\$1name*Sustitúyalo por CodeCatalyst el nombre de tu espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
*
```
**importante**
Puede usar cualquier valor en el elemento ``, pero debe ser el mismo en los elementos `` y ``. Esto permite incluir las credenciales especificadas en las solicitudes para CodeCatalyst.
Después de realizar estos cambios de configuración, puede crear el proyecto.
```
mvn compile
```
## Obtención de paquetes de repositorios de paquetes externos mediante CodeCatalyst
Puede instalar paquetes Maven desde repositorios públicos a través de un CodeCatalyst repositorio configurándolo con una conexión ascendente a la puerta de enlace que representa el repositorio de la puerta de enlace. Los paquetes instalados desde el repositorio de la puerta de enlace se ingieren y almacenan en su repositorio. CodeCatalyst
Actualmente, CodeCatalyst es compatible con los siguientes repositorios públicos de paquetes de Maven.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway
**Instalación de paquetes desde repositorios públicos de paquetes de Maven**
1. Si aún no lo ha hecho, configúrelo `mvn` con su repositorio de CodeCatalyst paquetes siguiendo los pasos que se indican en. [Obteniendo dependencias de CodeCatalyst](#mvn-fetch-dependencies)
1. Compruebe que el repositorio haya añadido el repositorio de puerta de enlace desde el que desea hacer la instalación como conexión ascendente. Para comprobar qué orígenes ascendentes se han añadido, o para añadir un repositorio de puerta de enlace como origen ascendente, siga las instrucciones indicadas en [Adición de un repositorio ascendente](packages-upstream-repositories-add.md).
Para obtener más información sobre cómo solicitar paquetes desde repositorios ascendentes, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
## Publicar paquetes en CodeCatalyst
Para publicar un paquete de Maven en un CodeCatalyst repositorio, también debes editar `~/.m2/settings.xml` el POM del proyecto. `mvn`
**Para usar `mvn` para publicar paquetes en tu repositorio de CodeCatalyst paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, elija **mvn** en la lista de clientes de administrador de paquetes.
1. Necesitará un token de acceso personal (PAT) para `mvn` autenticarse CodeCatalyst. Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Configure una variable de entorno en el equipo local con su PAT. Utilizará esta variable de entorno en el archivo `setting.xml`.
```
export CODECATALYST_ARTIFACTS_TOKEN=your_PAT
```
1. Agregue una sección `` a `settings.xml` con una referencia a la variable de entorno `CodeCatalyst_ARTIFACTS_TOKEN` para que Maven pase el token en las solicitudes HTTP.
```
...
repo-name
username
${env.CodeCatalyst_ARTIFACTS_TOKEN}
...
```
1. Agregue una sección `` al `pom.xml` de su proyecto.
```
...
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
...
```
Tras realizar estos cambios de configuración, puede crear el proyecto y publicarlo en el repositorio especificado.
```
mvn deploy
```
Puede navegar hasta el repositorio de paquetes en la CodeCatalyst consola para comprobar que el paquete se publicó correctamente.
## Publicación de paquetes externos
Puede publicar paquetes Maven de terceros en un CodeCatalyst repositorio con`mvn deploy:deploy-file`. Esto puede resultar útil para los usuarios que desean publicar paquetes, solo tienen archivos JAR y no tienen acceso al código fuente del paquete o a los archivos POM.
El comando `mvn deploy:deploy-file` generará un archivo POM en función de la información pasada en la línea de comandos.
En primer lugar, cree un PAT si no tiene uno.
**Creación de un token de acceso personal (PAT)**
1. En la barra de menú superior, elija su insignia de perfil y, a continuación, elija **Mi configuración**.
**sugerencia**
También puede encontrar su perfil de usuario en la página de miembros de un proyecto o espacio, seleccionando el nombre en la lista de miembros.
1. En **Nombre de PAT**, introduzca un nombre descriptivo para el PAT.
1. En **Fecha de vencimiento**, mantenga la fecha predeterminada o elija el icono del calendario para seleccionar una fecha personalizada. La fecha de vencimiento predeterminada es de 1 año a partir de la fecha actual.
1. Seleccione **Crear**.
También puede crear este token si elige **Clonar repositorio** para un repositorio de código fuente.
1. Guarde el secreto del PAT en un lugar seguro.
**importante**
El secreto del PAT solo se muestra una vez. No podrá recuperarlo después de cerrar la ventana.
**Publicación de paquetes de Maven externos**
1. Cree un archivo `~/.m2/settings.xml` con los siguientes contenidos:
```
repo_name
username
PAT}
```
1. Ejecute el comando `mvn deploy:deploy-file`:
```
mvn deploy:deploy-file -DgroupId=commons-cli \
-DartifactId=commons-cli \
-Dversion=1.4 \
-Dfile=./commons-cli-1.4.jar \
-Dpackaging=jar \
-DrepositoryId=repo-name \
-Durl=https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/
```
**nota**
El ejemplo anterior publica `commons-cli 1.4`. Modifique los argumentos GroupID, ArtifactID, version y file para publicar un JAR diferente.
Estas instrucciones se basan en los ejemplos de la [guía para implementar un repositorio remoto de terceros, JARs que](https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html) se encuentra en la documentación de *Apache Maven*.
Para obtener más información sobre estos temas, consulte el sitio web del Proyecto Apache Maven:
+ [Setting up Multiple Repositories](https://maven.apache.org/guides/mini/guide-multiple-repositories.html)
+ [Settings Reference](https://maven.apache.org/settings.html)
+ [Distribution Management](https://maven.apache.org/pom.html#Distribution_Management)
+ [Profiles](https://maven.apache.org/pom.html#Profiles)
# Publicación de paquetes con curl
En esta sección se muestra cómo usar el cliente HTTP `curl` para publicar paquetes de Maven en un CodeCatalyst repositorio de paquetes. Publicar artefactos con `curl` puede resultar útil si no tiene el cliente de Maven en sus entornos o si no desea instalarlo.
**Publicación de un paquete de Maven con `curl`**
1. Debe almacenar un token de acceso personal (PAT) en una variable de entorno para autenticarse con él. `curl` CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno y configurar la variable de entorno.
1. Cree un PAT siguiendo los pasos de [Concesión de acceso al repositorio para usuarios mediante tokens de acceso personal](ipa-tokens-keys.md). Copie el PAT para guardarlo en una variable de entorno.
1. En la línea de comandos del equipo local, configure una variable de entorno con el PAT.
```
export CodeCatalyst_ARTIFACTS_TOKEN=your_PAT
```
1. Use el siguiente `curl` comando para publicar el JAR en un CodeCatalyst repositorio. Sustituya *username**space\$1name*,*proj\$1name*, y *repo\$1name* por su nombre CodeCatalyst de usuario, nombre del espacio, nombre del proyecto y nombre del repositorio de paquetes.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.jar \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/path/to/my-app-1.0.jar
```
1. Utilice el siguiente `curl` comando para publicar el POM en un CodeCatalyst repositorio. Sustituya *username**space\$1name*,*proj\$1name*, y *repo\$1name* por su nombre CodeCatalyst de usuario, nombre del espacio, nombre del proyecto y nombre del repositorio de paquetes.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.pom \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/my-app-1.0.pom
```
1. En este punto, el paquete Maven estará en su CodeCatalyst repositorio con un estado de`Unfinished`. Para poder consumir el paquete, debe estar en el estado `Published`. Puede mover el paquete de `Unfinished` a `Published` subiendo un `maven-metadata.xml` archivo a su paquete o cambiando el estado en la CodeCatalyst consola.
1. Opción 1: usar el siguiente comando `curl` para añadir un archivo `maven-metadata.xml` al paquete. Sustituya *username**space\$1name*,*proj\$1name*, y *repo\$1name* por su nombre CodeCatalyst de usuario, nombre del espacio, nombre del proyecto y nombre del repositorio de paquetes.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/maven-metadata.xml \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/maven-metadata.xml
```
Lo que sigue es un ejemplo del contenido de un archivo `maven-metadata.xml`:
```
com.mycompany.app
my-app
1.0
1.0
1.0
20200731090423
```
1. Opción 2: actualice el estado del paquete a `Published` en la CodeCatalyst consola. Para obtener información sobre cómo actualizar el estado de la versión de un paquete, consulte [Actualización del estado de la versión de un paquete](working-with-packages-update-version-status.md).
Si solo tiene el archivo JAR de un paquete, puede publicar una versión del paquete consumible en un CodeCatalyst repositorio utilizando`mvn`. Esto puede resultar útil si no tiene acceso al código fuente o al POM del paquete. Para obtener más información, consulte [Publicación de paquetes externos](packages-maven-mvn.md#publishing-third-party-packages).
# Uso de sumas de comprobación e instantáneas de Maven
En las siguientes secciones se describe cómo utilizar las sumas de comprobación y las instantáneas de Maven en. CodeCatalyst
## Uso de sumas de comprobación de Maven
Cuando se publica un paquete de Maven en un repositorio de CodeCatalyst paquetes, la suma de comprobación asociada a cada *activo* o archivo del paquete se utiliza para validar la carga. Algunos ejemplos de activos son los archivos *jar*, *pom* y *war*. Para cada activo, el paquete de Maven contiene varios archivos de suma de comprobación que utilizan el nombre del activo con una extensión adicional, como `md5` o `sha1`. Por ejemplo, los archivos de suma de comprobación de un archivo denominado `my-maven-package.jar` podrían ser `my-maven-package.jar.md5` y `my-maven-package.jar.sha1`.
Cada paquete de Maven contiene también un archivo `maven-metadata.xml`. Este archivo debe cargarse para que la publicación se realice correctamente. Si se detecta una discrepancia en la suma de comprobación durante la carga de un archivo de paquete, la publicación se detiene. Esto podría impedir que `maven-metadata.xml` se cargase. Cuando eso sucede, el estado del paquete Maven se establece en `Unfinished`. No puede descargar activos que formen parte de un paquete con este estado.
Tenga en cuenta lo siguiente en caso de que haya una discrepancia en la suma de comprobación al publicar un paquete de Maven:
+ Si la discrepancia en la suma de comprobación ocurre antes de cargar `maven-metadata.xml`, el estado del paquete no se establecerá en `Unfinished`. El paquete no es visible y sus activos no se pueden consumir. Cuando esto suceda, intente una de las siguientes acciones y, a continuación, intente descargar el activo de nuevo.
+ Vuelva a ejecutar el comando que publica el paquete de Maven. Esto podría funcionar si un problema de red dañara el archivo de suma de comprobación durante la descarga. Si el reintento resuelve el problema de red, la suma de comprobación coincidirá y la descarga será correcta.
+ Si la nueva publicación del paquete Maven no funciona, elimínelo y vuelva a publicarlo.
+ Si la discrepancia en la suma de comprobación ocurre después de cargar `maven-metadata.xml`, el estado del paquete se establecerá en `Published`. Puede consumir cualquier activo del paquete, incluidos aquellos con discrepancias en la suma de comprobación. Cuando descargas un activo, la suma de comprobación generada por él CodeCatalyst se descarga junto con él. Si el archivo descargado está asociado a una discrepancia de suma de comprobación, es posible que el archivo de suma de comprobación descargado no coincida con la suma de comprobación que se cargó al publicar el paquete.
## Uso de instantáneas de Maven
Una *instantánea* de Maven es una versión especial de un paquete de Maven que hace referencia al código de rama de producción más reciente. Es una versión de desarrollo que precede a la versión de lanzamiento final. Puede identificar la versión de una instantánea de un paquete de Maven por el sufijo `SNAPSHOT` adjuntado a la versión del paquete. Por ejemplo, la instantánea de la versión `1.1` es `1.1-SNAPSHOT`. Para obtener más información, consulte [What is a SNAPSHOT version?](https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version) en el sitio web del Proyecto Apache Maven.
CodeCatalyst admite la publicación y el consumo de instantáneas de Maven. Puede publicar una instantánea de Maven en un CodeCatalyst repositorio o, si está conectado directamente, en un repositorio anterior. Sin embargo, no se admite una versión de instantánea que esté a la vez en un repositorio de paquetes y en uno de sus repositorios ascendentes. Por ejemplo, si subes un paquete de Maven con una versión `1.2-SNAPSHOT` a tu repositorio de paquetes, CodeCatalyst no es posible cargar un paquete de Maven con la misma versión de instantánea a uno de sus repositorios ascendentes. Este escenario puede arrojar resultados impredecibles.
Cuando se publica una instantánea de Maven, su versión anterior se conserva en una nueva versión llamada *compilación*. Cada vez que se publica una instantánea de Maven, se crea una nueva versión de compilación. Todas las versiones anteriores de una instantánea se mantienen en sus versiones de compilación. Cuando se publica una instantánea de Maven, su estado se establece en `Published` y el estado de la compilación que contiene la versión anterior se establece en `Unlisted`.
Si solicita una instantánea, se devuelve la versión con el estado `Published`. Esta es siempre la versión más reciente de la instantánea de Maven. También puede solicitar una compilación determinada de una instantánea.
Para eliminar todas las versiones compiladas de una instantánea de Maven, usa la consola. CodeCatalyst
# Uso NuGet
En estos temas se describe cómo consumir y publicar `NuGet` paquetes utilizando CodeCatalyst.
**nota**
CodeCatalyst es compatible con [NuGetla versión 4.8](https://docs.microsoft.com/en-us/nuget/release-notes/nuget-4.8-rtm) y superior.
**Topics**
+ [Uso CodeCatalyst con Visual Studio](packages-nuget-visual-studio.md)
+ [Configuración y uso de la CLI de nuget o dotnet](packages-nuget-cli.md)
+ [NuGet normalización del nombre del paquete, la versión y el nombre del activo](nuget-name-normalization.md)
+ [NuGet compatibilidad](packages-nuget-compatibility.md)
# Uso CodeCatalyst con Visual Studio
Puede consumir paquetes CodeCatalyst directamente desde Visual Studio.
Para configurar y utilizar NuGet con herramientas de CLI como `dotnet` o`nuget`, consulte[Configuración y uso de la CLI de nuget o dotnet](packages-nuget-cli.md).
**Contents**
+ [Configuración de Visual Studio con CodeCatalyst](#packages-nuget-vs-configure)
+ [Windows](#packages-nuget-vs-configure-windows)
+ [macOS](#packages-nuget-vs-configure-mac)
## Configuración de Visual Studio con CodeCatalyst
### Windows
**Para configurar Visual Studio con CodeCatalyst**
1. Se requiere un token de acceso personal (PAT) para autenticarse CodeCatalyst. Si ya tiene uno, puede utilizarlo. De lo contrario, siga las instrucciones en [Concesión de acceso al repositorio para usuarios mediante tokens de acceso personal](ipa-tokens-keys.md) para crear uno.
1. Utilice `nuget` o `dotnet` para configurar el repositorio de paquetes y las credenciales.
------
#### [ dotnet ]
**Usuarios de Linux y macOS:** dado que el cifrado no se admite en plataformas que no sean Windows, debe añadir la marca `--store-password-in-clear-text` al siguiente comando. Tenga en cuenta que esto almacenará la contraseña como texto sin formato en el archivo de configuración.
```
dotnet nuget add source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json --name repo_name --password PAT --username user_name
```
------
#### [ nuget ]
```
nuget sources add -name repo_name -Source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json -password PAT --username user_name
```
------
Ejemplo de código de salida:
```
Package source with Name: repo_name added successfully.
```
1. Configure Visual Studio para usar el nuevo origen de paquetes. En Visual Studio, elija **Tools** y, a continuación, **Options**.
1. En el menú **Opciones**, expanda la sección **NuGet Package Manager** y elija **Package Sources**.
1. En la lista de **fuentes de paquetes disponibles**, asegúrese de que su *repo\$1name* fuente esté habilitada. Si has configurado tu repositorio de paquetes con una conexión ascendente a la NuGet Galería, desactiva la fuente **nuget.org**.
### macOS
**Para configurar Visual Studio con CodeCatalyst**
1. Se requiere un token de acceso personal (PAT) para autenticarse CodeCatalyst. Si ya tiene uno, puede utilizarlo. De lo contrario, siga las instrucciones en [Concesión de acceso al repositorio para usuarios mediante tokens de acceso personal](ipa-tokens-keys.md) para crear uno.
1. Seleccione **Preferences** en la barra de menús.
1. En la **NuGet**sección, selecciona **Fuentes**.
1. Elija **Add** y añada la información del repositorio.
1. En **Nombre**, introduzca el nombre CodeCatalyst del repositorio de paquetes.
1. En **Ubicación**, introduzca el punto final CodeCatalyst del repositorio de paquetes. El siguiente fragmento de código muestra un ejemplo de punto de conexión. Sustituya *space-name**proj-name*, y *repo-name* por CodeCatalyst el nombre del espacio, el nombre del proyecto y el nombre del repositorio.
```
https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/
```
1. En **Username**, introduzca cualquier valor válido.
1. En **Password**, introduzca el PAT.
1. Elija **Añadir origen**.
1. Si ha configurado el repositorio de paquetes con una conexión ascendente a la NuGet Galería, desactive la fuente **nuget.org**.
Tras la configuración, Visual Studio puede consumir paquetes de su CodeCatalyst repositorio, de cualquiera de sus repositorios principales o de [NuGet.org](https://www.nuget.org/) si lo ha configurado como fuente principal. Para obtener más información sobre la exploración e instalación de NuGet paquetes en Visual Studio, consulte [Instalar y administrar paquetes en Visual Studio mediante el Administrador de NuGet paquetes](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-visual-studio) en la *NuGet documentación*.
# Configuración y uso de la CLI de nuget o dotnet
Puede utilizar herramientas de CLI, como `NuGet` y `dotnet` para publicar y consumir paquetes desde CodeCatalyst. Este documento proporciona información sobre la configuración de las herramientas CLI y su uso para publicar o consumir paquetes.
**Contents**
+ [Configurando NuGet con CodeCatalyst](#nuget-configure-cli)
+ [Consumir NuGet paquetes de un repositorio CodeCatalyst](#nuget-consume-cli)
+ [Consumir NuGet paquetes desde NuGet .org hasta CodeCatalyst](#nuget-consume-nuget-gallery)
+ [Publicar paquetes en NuGet CodeCatalyst](#nuget-publish-cli)
## Configurando NuGet con CodeCatalyst
Para NuGet configurarlo CodeCatalyst, añada un terminal de repositorio y un token de acceso personal a su archivo de NuGet configuración para permitir `nuget` o conectarse `dotnet` a su CodeCatalyst repositorio de paquetes.
**Para configurarlo NuGet con su repositorio de CodeCatalyst paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Conectar al repositorio**, elija **NuGet**o **dotnet** de la lista de clientes del administrador de paquetes.
1. Necesitará un token de acceso personal (PAT) para autenticarse. NuGet CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Configure `nuget` o `dotnet` utilice el NuGet punto final y la CodeCatalyst PAT de su repositorio. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *username*Sustitúyalo por tu nombre CodeCatalyst de usuario.
+ *PAT*Sustitúyalo por tu CodeCatalyst PAT.
+ Reemplácelo por *space\$1name* CodeCatalyst el nombre de su espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
1. En `nuget`, utilice el comando `nuget sources add`:
```
nuget sources add -name "repo_name" -Source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -username "username" -password "PAT"
```
1. En `dotnet`, utilice el comando `dotnet nuget add source`:
**Usuarios de Linux y macOS:** dado que el cifrado no se admite en plataformas que no sean Windows, debe añadir la marca `--store-password-in-clear-text` al siguiente comando. Tenga en cuenta que esto almacenará la contraseña como texto sin formato en el archivo de configuración.
```
dotnet nuget add source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -n "proj_name/repo_name" -u "username" -p "PAT" --store-password-in-clear-text
```
Una vez que lo haya configurado NuGet CodeCatalyst, puede [consumir NuGet los paquetes](#nuget-consume-cli) que estén almacenados en su CodeCatalyst repositorio o en uno de sus repositorios anteriores y [publicarlos NuGet ](#nuget-publish-cli) en su CodeCatalyst repositorio.
## Consumir NuGet paquetes de un repositorio CodeCatalyst
Una vez que lo haya [configurado NuGet CodeCatalyst](#nuget-configure-cli), podrá consumir NuGet los paquetes que estén almacenados en su CodeCatalyst repositorio o en uno de sus repositorios ascendentes.
Para consumir una versión de paquete de un CodeCatalyst repositorio o de uno de sus repositorios principales con nuget o dotnet, ejecuta el siguiente comando. *packageName*Sustitúyalo por el nombre del paquete que quieres consumir y *packageSourceName* por el nombre fuente del repositorio de CodeCatalyst paquetes en el archivo de NuGet configuración, que debe ser el nombre del repositorio.
**Instalación de un paquete con `dotnet`**
```
dotnet add packageName --source packageSourceName
```
**Instalación de un paquete con `nuget`**
```
nuget install packageName --source packageSourceName
```
Para obtener más información, consulte [Manage packages using the nuget CLI](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-nuget-cli) o [Install and manage packages using the dotnet CLI](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-dotnet-cli) en la *documentación de Microsoft*.
## Consumir NuGet paquetes desde NuGet .org hasta CodeCatalyst
Puede consumir NuGet paquetes de [NuGet.org](https://www.nuget.org/) a través de un CodeCatalyst repositorio configurando el repositorio con una conexión ascendente a **NuGet.org**. Los paquetes consumidos desde **NuGet.org** se ingieren y almacenan en tu CodeCatalyst repositorio.
**Para consumir paquetes de .org NuGet**
1. Si aún no lo has hecho, configura tu administrador de NuGet paquetes con tu repositorio de CodeCatalyst paquetes siguiendo los pasos que se indican en[Configurando NuGet con CodeCatalyst](#nuget-configure-cli).
1. Asegúrese de que su repositorio haya agregado **NuGet.org** como conexión ascendente. **Puedes comprobar qué fuentes originales se han añadido o añadir **Nuget.org** como fuente principal siguiendo las instrucciones que se indican en el repositorio de la tienda [Adición de un repositorio ascendente](packages-upstream-repositories-add.md) y seleccionando el repositorio de la tienda. NuGet **
## Publicar paquetes en NuGet CodeCatalyst
Una vez que lo haya [configurado NuGet CodeCatalyst](#nuget-configure-cli), puede usar `nuget` o publicar las versiones de `dotnet` los paquetes en los repositorios. CodeCatalyst
Para enviar una versión de paquete a un CodeCatalyst repositorio, ejecute el siguiente comando con la ruta completa del `.nupkg` archivo y el nombre de la fuente del CodeCatalyst repositorio en el archivo de NuGet configuración.
**Publicación de un paquete con `dotnet`**
```
dotnet nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
**Publicación de un paquete con `nuget`**
```
nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
# NuGet normalización del nombre del paquete, la versión y el nombre del activo
CodeCatalyst normaliza los nombres de los paquetes y activos y las versiones de los paquetes antes de almacenarlos, lo que significa que los nombres o las versiones CodeCatalyst pueden ser diferentes a los que se proporcionaron cuando se publicó el paquete o el activo.
**Normalización de nombres de paquetes:** CodeCatalyst normaliza los nombres de los NuGet paquetes al convertir todas las letras a minúsculas.
**Normalización de la versión del paquete:** CodeCatalyst normaliza las versiones NuGet del paquete utilizando el mismo patrón que NuGet. La siguiente información proviene de los [números de versión normalizados](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers) de la NuGet documentación.
+ Los ceros iniciales se eliminan de los números de versión:
+ `1.00` se trata como `1.0`
+ `1.01.1` se trata como `1.1.1`
+ `1.00.0.1` se trata como `1.0.0.1`
+ Se omitirá un cero en la cuarta parte del número de versión:
+ `1.0.0.0` se trata como `1.0.0`
+ `1.0.01.0` se trata como `1.0.1`
+ SemVer Se han eliminado los metadatos de la compilación 2.0.0:
+ `1.0.7+r3456` se trata como `1.0.7`
**Normalización del nombre del activo del paquete:** CodeCatalyst construye el nombre NuGet del activo del paquete a partir del nombre y la versión del paquete normalizados.
# NuGet compatibilidad
Esta guía contiene información sobre CodeCatalyst la compatibilidad con diferentes NuGet herramientas y versiones.
**Topics**
+ [NuGet Compatibilidad general](#nuget-version-support)
+ [NuGet soporte de línea de comandos](#nuget-command-line-support)
## NuGet Compatibilidad general
CodeCatalyst es compatible con NuGet 4.8 y versiones posteriores.
CodeCatalyst solo es compatible con la versión 3 del protocolo NuGet HTTP. Esto significa que algunos comandos CLI que se basan en la V2 del protocolo no son compatibles. Consulte la siguiente sección [soporte de comandos nuget](#nuget-command-support) para obtener más información.
CodeCatalyst no es compatible con la versión PowerShellGet 2.x.
## NuGet soporte de línea de comandos
CodeCatalyst admite las herramientas CLI NuGet (`nuget`) y .NET Core (`dotnet`).
### soporte de comandos nuget
Como CodeCatalyst solo es compatible con la versión 3 NuGet del protocolo HTTP, los siguientes comandos no funcionarán cuando se utilicen con CodeCatalyst recursos:
+ `list`: El comando `nuget list` muestra una lista de paquetes de una fuente determinada. Para obtener una lista de los paquetes de un repositorio de CodeCatalyst paquetes, navegue hasta el repositorio de la CodeCatalyst consola.
# Uso de Python
En estos temas se describe cómo usar `pip` el administrador de paquetes Python y `twine` la utilidad de publicación de paquetes Python con CodeCatalyst.
**Topics**
+ [Configuración de pip e instalación de paquetes de Python](packages-python-pip.md)
+ [Configuración de Twine y publicación de paquetes de Python](packages-python-twine.md)
+ [Normalización de nombres de paquetes de Python](python-name-normalization.md)
+ [Compatibilidad con Python](packages-python-compatibility.md)
# Configuración de pip e instalación de paquetes de Python
Para usarlo `pip` con CodeCatalyst, debe conectarse `pip` a su repositorio de paquetes y proporcionar un token de acceso personal para la autenticación. Puedes ver las instrucciones para conectarte `pip` al repositorio de paquetes en la CodeCatalyst consola. Después de autenticarse y conectarse `pip` a CodeCatalyst, puede ejecutar `pip` comandos.
**Contents**
+ [Instalación de paquetes de Python desde CodeCatalyst pip](#pip-install)
+ [Consumir paquetes de Python desde PyPI hasta CodeCatalyst](#pip-install-pypi)
+ [soporte de comandos pip](#pip-command-support)
+ [Comandos compatibles que interactúan con un repositorio](#supported-pip-commands-that-interact-with-a-repository)
+ [Comandos del lado del cliente compatibles](#supported-pip-client-side-commands)
## Instalación de paquetes de Python desde CodeCatalyst pip
Las siguientes instrucciones explican cómo configurar `pip` la instalación de paquetes de Python desde su repositorio de CodeCatalyst paquetes o uno de sus repositorios ascendentes.
**Para configurar y usar `pip` para instalar paquetes de Python desde su repositorio de CodeCatalyst paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, elija **pip** de la lista de clientes del administrador de paquetes.
1. Necesitarás un token de acceso personal (PAT) para autenticar a pip. CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Usa el `pip config` comando para configurar la URL y las CodeCatalyst credenciales del registro. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *username*Sustitúyala por tu nombre CodeCatalyst de usuario.
+ *PAT*Sustitúyalo por tu CodeCatalyst PAT.
+ Reemplácelo por *space\$1name* CodeCatalyst el nombre de su espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
pip config set global.index-url https://username:PAT@https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/simple/
```
1. Suponiendo que un paquete esté presente en su repositorio o en uno de sus repositorios ascendentes, puede instalarlo con `pip install`. Por ejemplo, utilice el siguiente comando para instalar el paquete `requests`.
```
pip install requests
```
Utilice la `-i` opción para volver temporalmente a instalar paquetes desde [https://pypi.org](https://pypi.org) en lugar de desde su repositorio de CodeCatalyst paquetes.
```
pip install -i https://pypi.org/simple requests
```
## Consumir paquetes de Python desde PyPI hasta CodeCatalyst
**Puede consumir paquetes de Python del [Python Package Index (PyPI](https://www.pypi.org/)) a través de CodeCatalyst un repositorio configurando el repositorio con una conexión ascendente a PyPI.** Los paquetes consumidos por **PyPI** se ingieren y almacenan en su repositorio. CodeCatalyst
**Consumo de paquetes desde PyPI**
1. Si aún no lo has hecho, configura pip con tu repositorio de CodeCatalyst paquetes siguiendo los pasos que se indican en. [Instalación de paquetes de Python desde CodeCatalyst pip](#pip-install)
1. Asegúrese de que el repositorio haya añadido **PyPI** como origen ascendente. Puede comprobar qué orígenes ascendentes se añaden, o añadir **PyPI** como origen ascendente, siguiendo las instrucciones de [Adición de un repositorio ascendente](packages-upstream-repositories-add.md) y seleccionando el repositorio de la **tienda de PyPI**.
Para obtener más información sobre cómo solicitar paquetes desde repositorios ascendentes, consulte [Solicitar una versión de paquete con repositorios ascendentes](packages-upstream-repositories-request.md).
## soporte de comandos pip
En las siguientes secciones se resumen los comandos pip compatibles con los CodeCatalyst repositorios, además de los comandos específicos que no lo son.
**Topics**
+ [Comandos compatibles que interactúan con un repositorio](#supported-pip-commands-that-interact-with-a-repository)
+ [Comandos del lado del cliente compatibles](#supported-pip-client-side-commands)
### Comandos compatibles que interactúan con un repositorio
En esta sección se enumeran los comandos `pip` en los que el cliente `pip` realiza una o más solicitudes al registro con el que se ha configurado. Se ha comprobado que estos comandos funcionan correctamente cuando se invocan en un CodeCatalyst repositorio de paquetes.
****
| Comando | Description (Descripción) |
| --- | --- |
| [install](https://pip.pypa.io/en/stable/reference/pip_install/) | Instalar paquetes. |
| [download](https://pip.pypa.io/en/stable/reference/pip_download/) | Descargar paquetes. |
CodeCatalyst no implementa`pip search`. Si lo has configurado `pip` con un repositorio de CodeCatalyst paquetes, al ejecutar `pip search` se buscarán y mostrarán los paquetes de [PyPI](https://pypi.org/).
### Comandos del lado del cliente compatibles
Estos comandos no requieren ninguna interacción directa con un repositorio, por lo que CodeCatalyst no es necesario hacer nada para respaldarlos.
****
| Comando | Description (Descripción) |
| --- | --- |
| [uninstall](https://pip.pypa.io/en/stable/reference/pip_uninstall/) | Desinstalar paquetes. |
| [freeze](https://pip.pypa.io/en/stable/reference/pip_freeze/) | Salida de paquetes instalados en formato de requisitos. |
| [list](https://pip.pypa.io/en/stable/reference/pip_list/) | Ver una lista de los paquetes instalados. |
| [show](https://pip.pypa.io/en/stable/reference/pip_show/) | Mostrar información acerca de los paquetes instalados. |
| [check](https://pip.pypa.io/en/stable/reference/pip_check/) | Compruebe que los paquetes instalados tengan dependencias compatibles. |
| [config](https://pip.pypa.io/en/stable/reference/pip_config/) | Administrar la configuración local y global. |
| [wheel](https://pip.pypa.io/en/stable/reference/pip_wheel/) | Construir ruedas a partir de sus necesidades. |
| [hash](https://pip.pypa.io/en/stable/reference/pip_hash/) | Calcular los hashes de los archivos de los paquetes. |
| [completion](https://pip.pypa.io/en/stable/user_guide/#command-completion) | Ayuda a completar los comandos. |
| [debug](https://pip.pypa.io/en/stable/reference/pip_debug/) | Mostrar información útil para depuración. |
| help | Mostrar la ayuda para los comandos. |
# Configuración de Twine y publicación de paquetes de Python
Para usarlo `twine` con CodeCatalyst, debe conectarse `twine` a su repositorio de paquetes y proporcionar un token de acceso personal para la autenticación. Puedes ver las instrucciones para conectarte `twine` al repositorio de paquetes en la CodeCatalyst consola. Después de autenticarse y conectarse `twine` a CodeCatalyst, puede ejecutar `twine` comandos.
## Publicar paquetes CodeCatalyst con Twine
Las siguientes instrucciones explican cómo autenticarse y conectarse `twine` a su repositorio de CodeCatalyst paquetes.
**Para configurar y usar `twine` para publicar paquetes en su repositorio de CodeCatalyst paquetes**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En la página de información general del proyecto, seleccione **Paquetes**.
1. Elija su repositorio de paquetes de la lista de repositorios de paquetes.
1. Seleccione **Establecer conexión con el repositorio**.
1. En el cuadro de diálogo **Establecer conexión con el repositorio**, elija **Twine** de la lista de clientes del administrador de paquetes.
1. Necesitarás un token de acceso personal (PAT) para autenticar a Twine. CodeCatalyst Si ya tiene uno, puede utilizarlo. De lo contrario, puede crear uno aquí.
1. Seleccione **Crear token**.
1. Seleccione **Copiar** para copiar el PAT.
**aviso**
Después de cerrar el cuadro de diálogo, no podrá volver a ver ni copiar el PAT.
1. Puede configurar twine con un archivo `.pypirc` o con variables de entorno.
1. **Configuración con un archivo `.pypirc`.**
Abra `~/.pypirc` en el editor que prefiera.
Agregue un servidor de índices para CodeCatalyst el que incluya el repositorio, el nombre de usuario y la PAT que creó y copió en el paso anterior. Reemplace los siguientes valores.
**nota**
Si va a copiar las instrucciones de la consola, los siguientes valores deben actualizarse automáticamente y no deben cambiarse.
+ *username*Sustitúyalo por tu nombre CodeCatalyst de usuario.
+ *PAT*Sustitúyalo por tu CodeCatalyst PAT.
+ Reemplácelo por *space\$1name* CodeCatalyst el nombre de su espacio.
+ *proj\$1name*Sustitúyalo por CodeCatalyst el nombre de tu proyecto.
+ *repo\$1name*Sustitúyalo por el nombre CodeCatalyst del repositorio de paquetes.
```
[distutils]
index-servers = proj-name/repo-name
[proj-name/repo-name]
repository = https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/
password = PAT
username = username
```
1. **Configuración con variables de entorno**
Configure las siguientes variables de entorno. En el `TWINE_REPOSITORY_URL` valor *space\$1name**proj\$1name*, actualice y *repo\$1name* con los nombres de los repositorios de paquetes, proyectos y CodeCatalyst espacios.
```
export TWINE_USERNAME=username
```
```
export TWINE_PASSWORD=PAT
```
```
export TWINE_REPOSITORY_URL="https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/"
```
1. Publique una distribución de Python con el comando `twine upload`.
# Normalización de nombres de paquetes de Python
CodeCatalyst normaliza los nombres de los paquetes antes de almacenarlos, lo que significa que los nombres de los paquetes CodeCatalyst pueden ser diferentes del nombre proporcionado cuando se publicó el paquete.
Para los paquetes de Python, al realizar la normalización, el nombre del paquete aparece en minúsculas y todas las instancias de los caracteres `.`, `-` y `_` se sustituyen por un solo carácter `-`. Por lo tanto, los nombres de los paquetes `pigeon_cli` y `pigeon.cli` se normalizan y se almacenan como `pigeon-cli`. El nombre no normalizado lo pueden utilizar pip y twine. Para obtener más información sobre la normalización de los nombres de paquete de Python, consulte [PEP 503](https://www.python.org/dev/peps/pep-0503/#normalized-names) en la documentación de Python.
# Compatibilidad con Python
Si bien CodeCatalyst no es compatible con la `/simple/` API, sí admite las operaciones de la `Legacy` API. CodeCatalyst no admite las operaciones de PyPI `XML-RPC` o `JSON` API.
Para obtener más información, consulte lo siguiente en el GitHub repositorio de Python Packaging Authority.
+ [API heredada](https://warehouse.pypa.io/api-reference/legacy.html)
+ [API XML-RPC](https://github.com/pypi/warehouse/blob/main/docs/dev/api-reference/xml-rpc.rst)
+ [API JSON](https://docs.pypi.org/api/json/)
# Cuotas para paquetes
En la siguiente tabla se describen las cuotas y los límites de los paquetes en Amazon CodeCatalyst. Para obtener más información sobre las cuotas en Amazon CodeCatalyst, consulta[Cuotas de CodeCatalyst](quotas.md).
| Recurso | Cuota predeterminada |
| --- | --- |
| Repositorios de paquetes | Máximo de 1000 por espacio. |
| Repositorios ascendentes directos | Máximo de 10 por repositorio de paquetes. |
| Repositorios de paquetes ascendentes buscados | Máximo de 25 repositorios ascendentes buscados por versión de paquete solicitada. |
| Tamaño del archivo de activos del paquete | Máximo de 5 GB por activo de paquetes. |
| Activos de paquetes | Máximo de 150 por versión de paquete. |