Esta es una implementación prototipo de una utilidad de firma de solicitudes para usar con OpenSearch sin servidor (AOSS). (Actualmente) está destinado a proporcionar una interfaz similar a curl para consultar la instancia AOSS del Registro PDS utilizando una identidad de usuario de Cognito.
Es posible que se creen funciones adicionales en el futuro.
Credenciales personales de usuario/contraseña para un usuario de Cognito autorizado para el Registro AOSS
Pitón >=3.9
Variables de entorno (póngase en contacto con el desarrollador para conocer los valores)
exportar REQUEST_SIGNER_AWS_ACCOUNT='' exportar REQUEST_SIGNER_AWS_REGION='' exportar REQUEST_SIGNER_CLIENT_ID='' exportar REQUEST_SIGNER_USER_POOL_ID='' exportar REQUEST_SIGNER_IDENTITY_POOL_ID='' exportar REQUEST_SIGNER_AOSS_ENDPOINT='' exportar REQUEST_SIGNER_COGNITO_USER='' exportar REQUEST_SIGNER_COGNITO_PASSWORD=''
Clonar el repositorio
git clone https://github.com/NASA-PDS/registry-client.git cd registry-client
Crear un entorno virtual
python -m venv venv source ./venv/bin/activate
Instale la herramienta en el entorno virtual.
pip install --editable .[dev]
Ejecute la herramienta directamente
registry-client --help
Se espera que todos los usuarios y desarrolladores del software NASA-PDS respeten nuestro Código de conducta. Lea esto para asegurarse de comprender las expectativas de nuestra comunidad.
Para desarrollar este proyecto, utilice su editor de texto favorito o un entorno de desarrollo integrado con soporte para Python, como PyCharm.
Para obtener información sobre cómo contribuir a las bases de código de NASA-PDS, consulte nuestras pautas de contribución.
Instálelo en modo editable y con dependencias de desarrollador adicionales en el entorno virtual de su elección:
pip install --editable '.[dev]'
Cree una línea de base para cualquier secreto (direcciones de correo electrónico, contraseñas, claves API, etc.) en el repositorio:
detect-secrets scan . --all-files --disable-plugin AbsolutePathDetectorExperimental --exclude-files '.secrets..*' --exclude-files '.git.*' --exclude-files '.mypy_cache' --exclude-files '.pytest_cache' --exclude-files '.tox' --exclude-files '.venv' --exclude-files 'venv' --exclude-files 'dist' --exclude-files 'build' --exclude-files '.*.egg-info' > .secrets.baseline
Revise los secretos para determinar cuáles deben permitirse y cuáles son falsos positivos:
detect-secrets audit .secrets.baseline
Elimine cualquier secreto que no deba ser visto por el público. Luego puede agregar el archivo de referencia a la confirmación:
git add .secrets.baseline
Luego, configure los ganchos pre-commit :
pre-commit install pre-commit install -t pre-push pre-commit install -t prepare-commit-msg pre-commit install -t commit-msg
Luego, estos ganchos verificarán si hay confirmaciones futuras que puedan contener secretos. También verifican el formato del código, el cumplimiento de PEP8, sugerencias de tipo, etc.
? Nota: Se requiere una configuración única tanto para admitir detect-secrets como en su configuración global de Git. Consulte la entrada de la wiki sobre Secretos para saber cómo hacerlo.
Para aislar y poder reproducir el entorno de este paquete, debe utilizar un entorno virtual de Python. Para hacerlo, ejecute:
python -m venv venv
Luego use exclusivamente venv/bin/python , venv/bin/pip , etc.
Si tiene tox instalado y desea que cree su entorno e instale dependencias, ejecute:
tox --devenv <name you'd like for env> -e dev
Las dependencias para el desarrollo se especifican como dev extras_require en setup.cfg ; se instalan en el entorno virtual de la siguiente manera:
pip install --editable '.[dev]'
Todo el código fuente está en un subdirectorio bajo src .
Debes actualizar el archivo setup.cfg con:
nombre de tu módulo
licencia, apache predeterminado, actualizar si es necesario
descripción
URL de descarga, cuando publique su paquete en github, agregue la URL aquí
palabras clave
clasificadores
install_requires, agrega las dependencias de tu paquete
extras_require, agrega las Dependencias de desarrollo de tu paquete
Entry_points, cuando se puede llamar a su paquete en la línea de comando, esto ayuda a implementar puntos de entrada de líneas de comando que apunten a scripts en su paquete.
Para obtener detalles sobre el paquete, consulte https://packaging.python.org/tutorials/packaging-projects/ como referencia.
Es conveniente utilizar el paquete ConfigParser para gestionar la configuración. Permite una configuración predeterminada que el usuario puede sobrescribir en un archivo específico de su entorno. Consulte https://pymotw.com/2/ConfigParser/
Por ejemplo:
candidates = ['my_pds_module.ini', 'my_pds_module.ini.default'] found = parser.read(candidates)
No debe utilizar print() con el fin de registrar información sobre la ejecución de su código. Dependiendo de dónde se ejecute el código, esta información podría redirigirse a archivos de registro específicos.
Para que eso funcione, comience cada archivo Python con:
"""Mi módulo."""importar logginglogger = logging.getLogger(__name__)
Para registrar un mensaje:
logger.info("my message") En tu rutina main , incluye:
logging.basicConfig(level=logging.INFO)
para configurar un sistema de registro básico.
El dev extras_require incluido en el repositorio de plantillas instala black , flake8 (más algunos complementos) y mypy junto con la configuración predeterminada para todos ellos. Puedes ejecutar todo esto (¡y más!) con:
tox -e lint
Para que tu código sea legible, debes cumplir con la guía de estilo PEP8. Nuestro estilo de código se aplica automáticamente a través de black y flake8. Consulte la sección Herramientas para obtener información sobre cómo invocar el canal de linting.
❗Nota importante para usuarios de plantillas❗ El archivo de configuración de confirmación previa incluido ejecuta flake8 (junto con mypy ) en toda la carpeta src y no solo en los archivos modificados. Si está convirtiendo una base de código preexistente a esta plantilla, eso puede generar muchos errores que no está listo para abordar.
En su lugar, puede ejecutar flake8 solo sobre una diferencia de los cambios actuales que se están realizando modificando la línea entry pre-commit :
entry: git diff -u | flake8 --diff
O puede cambiar la configuración pre-commit para que flake8 solo se llame en archivos modificados que coincidan con ciertos criterios de filtrado:
- repo: local hooks: - id: flake8 name: flake8 entry: flake8 files: ^src/|tests/ language: system
Python ofrece una gran variedad de bibliotecas. En el ámbito de PDS, para el uso más actual deberíamos utilizar:
| Biblioteca | Uso |
|---|---|
| analizador de configuración | administrar y analizar archivos de configuración |
| analizar argumentos | documentación y análisis de argumentos de línea de comando |
| solicitudes | interactuar con las API web |
| lxml | leer/escribir archivos XML |
| json | leer/escribir archivos JSON |
| pyyaml | leer/escribir archivos YAML |
| pistacho | generar archivos a partir de plantillas |
Algunos de ellos están integrados en Python 3; otros son complementos de código abierto que puede incluir en su requirements.txt .
Esta sección describe las pruebas para su paquete.
Una "compilación" completa que incluye ejecución de pruebas, linting ( mypy , black , flake8 , etc.) y compilación de documentación se ejecuta mediante:
tox
Su proyecto debe tener pruebas unitarias integradas, pruebas funcionales, de validación, de aceptación, etc.
Para pruebas unitarias, consulte el módulo unittest, integrado en Python 3.
Los objetos de prueba deben estar en los módulos test de los paquetes o preferiblemente en el directorio 'pruebas' del proyecto que refleja la estructura del paquete del proyecto.
Nuestras pruebas unitarias se lanzan con el comando:
pytest
Si desea que sus pruebas se ejecuten automáticamente a medida que realiza cambios, inicie pytest en modo de observación con:
ptw
Se debe usar el behave package y enviar los resultados de la prueba a "testrail".
Vea un ejemplo en https://github.com/NASA-PDS/pds-doi-service#behavioral-testing-for-integration--testing
Su proyecto debe utilizar Sphinx para crear su documentación. La plantilla de documentación de PDS ya está configurada como parte de la compilación predeterminada. Puedes crear los documentos de tus proyectos con:
python setup.py build_sphinx
Puede acceder a los archivos de compilación en el siguiente directorio relativo a la raíz del proyecto:
build/sphinx/html/
pip install wheel python setup.py sdist bdist_wheel
Los paquetes PDS de la NASA se pueden publicar automáticamente utilizando Roundup Action, que aprovecha las acciones de GitHub para realizar una integración continua automatizada y una entrega continua. Se proporciona un flujo de trabajo predeterminado que incluye el resumen en el archivo .github/workflows/unstable-cicd.yaml . (Inestable aquí significa una liberación provisional).
Crea el paquete:
python setup.py bdist_wheel
Publíquelo como una versión de Github.
Publicar en PyPI (necesita una cuenta PyPI y configurar $HOME/.pypirc ):
pip install twine twine upload dist/*
O publique en Test PyPI (necesita una cuenta de Test PyPI y configure $HOME/.pypirc ):
pip install twine twine upload --repository testpypi dist/*
El repositorio de plantillas viene con nuestros dos flujos de trabajo de CI/CD "estándar", stable-cicd y unstable-cicd . La compilación inestable se ejecuta con cualquier inserción en main (± ignorando cambios en archivos específicos) y la compilación estable se ejecuta con la inserción de una rama de lanzamiento del formulario release/<release version> . Ambos hacen uso de nuestro paso de creación de acciones de GitHub, Roundup. El unstable-cicd generará (y actualizará constantemente) una versión SNAPSHOT. Si no ha realizado una versión formal del software, terminará con una versión v0.0.0-SNAPSHOT (consulte NASA-PDS/roundup-action#56 para obtener detalles específicos).
