Il s'agit d'un prototype d'implémentation d'un utilitaire de signature de requêtes à utiliser avec OpenSearch (AOSS) sans serveur. Il est (actuellement) destiné à fournir une interface de type curl pour interroger l'instance AOSS du registre PDS à l'aide d'une identité d'utilisateur Cognito.
Des fonctionnalités supplémentaires pourraient être développées à l’avenir.
Identifiants d'utilisateur/pass personnels pour un utilisateur Cognito autorisé pour le registre AOSS
Python >=3,9
Variables d'environnement (contacter le développeur pour les valeurs)
export REQUEST_SIGNER_AWS_ACCOUNT='' export REQUEST_SIGNER_AWS_REGION='' export REQUEST_SIGNER_CLIENT_ID='' export REQUEST_SIGNER_USER_POOL_ID='' export REQUEST_SIGNER_IDENTITY_POOL_ID='' export REQUEST_SIGNER_AOSS_ENDPOINT='' export REQUEST_SIGNER_COGNITO_USER=''export REQUEST_SIGNER_COGNITO_PASSWORD=''
Cloner le référentiel
git clone https://github.com/NASA-PDS/registry-client.git cd registry-client
Créer un environnement virtuel
python -m venv venv source ./venv/bin/activate
Installer l'outil dans l'environnement virtuel
pip install --editable .[dev]
Exécutez l'outil directement
registry-client --help
Tous les utilisateurs et développeurs du logiciel NASA-PDS sont tenus de respecter notre code de conduite. Veuillez lire ceci pour vous assurer de bien comprendre les attentes de notre communauté.
Pour développer ce projet, utilisez votre éditeur de texte préféré ou un environnement de développement intégré prenant en charge Python, tel que PyCharm.
Pour plus d'informations sur la façon de contribuer aux bases de code NASA-PDS, veuillez consulter nos directives de contribution.
Installez en mode modifiable et avec des dépendances de développeur supplémentaires dans l'environnement virtuel de votre choix :
pip install --editable '.[dev]'
Créez une référence pour tous les secrets (adresses e-mail, mots de passe, clés API, etc.) dans le référentiel :
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
Passez en revue les secrets pour déterminer lesquels doivent être autorisés et lesquels sont des faux positifs :
detect-secrets audit .secrets.baseline
Veuillez supprimer tous les secrets qui ne doivent pas être vus par le public. Vous pouvez ensuite ajouter le fichier de base au commit :
git add .secrets.baseline
Ensuite, configurez les hooks pre-commit :
pre-commit install pre-commit install -t pre-push pre-commit install -t prepare-commit-msg pre-commit install -t commit-msg
Ces hooks vérifieront ensuite tous les futurs commits susceptibles de contenir des secrets. Ils vérifient également le formatage du code, la conformité PEP8, les astuces de saisie, etc.
? Remarque : Une configuration unique est requise à la fois pour prendre en charge detect-secrets et dans votre configuration Git globale. Consultez l'entrée wiki sur les secrets pour savoir comment procéder.
Pour isoler et pouvoir reproduire l'environnement de ce package, vous devez utiliser un environnement virtuel Python. Pour ce faire, exécutez :
python -m venv venv
Utilisez ensuite exclusivement venv/bin/python , venv/bin/pip , etc.
Si tox est installé et que vous souhaitez qu'il crée votre environnement et installe les dépendances pour vous, exécutez :
tox --devenv <name you'd like for env> -e dev
Les dépendances pour le développement sont spécifiées comme dev extras_require dans setup.cfg ; ils sont installés dans l'environnement virtuel comme suit :
pip install --editable '.[dev]'
Tout le code source se trouve dans un sous-répertoire sous src .
Vous devez mettre à jour le fichier setup.cfg avec :
nom de votre module
licence, apache par défaut, mise à jour si nécessaire
description
URL de téléchargement, lorsque vous publiez votre package sur github, ajoutez l'URL ici
mots-clés
classificateurs
install_requires, ajoutez les dépendances de votre package
extras_require, ajoutez les dépendances de développement de votre package
Entry_points, lorsque votre package peut être appelé en ligne de commande, cela permet de déployer des points d'entrée en ligne de commande pointant vers les scripts de votre package.
Pour les détails de l'emballage, voir https://packaging.python.org/tutorials/packaging-projects/ comme référence.
Il est pratique d'utiliser le package ConfigParser pour gérer la configuration. Il permet une configuration par défaut qui peut être écrasée par l'utilisateur dans un fichier spécifique de son environnement. Voir https://pymotw.com/2/ConfigParser/
Par exemple:
candidates = ['my_pds_module.ini', 'my_pds_module.ini.default'] found = parser.read(candidates)
Vous ne devez pas utiliser print() dans le but de consigner des informations sur l'exécution de votre code. Selon l'endroit où le code s'exécute, ces informations peuvent être redirigées vers des fichiers journaux spécifiques.
Pour que cela fonctionne, démarrez chaque fichier Python avec :
"""Mon module."""import logginglogger = logging.getLogger(__name__)
Pour enregistrer un message :
logger.info("my message") Dans votre routine main , incluez :
logging.basicConfig(level=logging.INFO)
pour configurer un système de journalisation de base.
Le dev extras_require inclus dans le dépôt de modèles installe black , flake8 (plus quelques plugins) et mypy avec la configuration par défaut pour chacun d'eux. Vous pouvez exécuter tout cela (et bien plus encore !) avec :
tox -e lint
Pour que votre code soit lisible, vous devez vous conformer au guide de style PEP8. Notre style de code est automatiquement appliqué via black et flake8. Consultez la section Outillage pour plus d’informations sur l’appel du pipeline de peluchage.
❗Remarque importante pour les utilisateurs de modèles❗ Le fichier de configuration de pré-validation inclus exécute flake8 (avec mypy ) sur l'ensemble du dossier src et pas seulement sur les fichiers modifiés. Si vous convertissez une base de code préexistante vers ce modèle, cela peut entraîner de nombreuses erreurs que vous n'êtes pas prêt à gérer.
Vous pouvez à la place exécuter flake8 uniquement sur une différence des modifications en cours en modifiant la ligne entry pre-commit :
entry: git diff -u | flake8 --diff
Ou vous pouvez modifier la configuration pre-commit afin que flake8 ne soit appelé que sur les fichiers modifiés qui correspondent à certains critères de filtrage :
- repo: local hooks: - id: flake8 name: flake8 entry: flake8 files: ^src/|tests/ language: system
Python propose une grande variété de bibliothèques. Dans le cadre du PDS, pour l'utilisation la plus actuelle, nous devrions utiliser :
| Bibliothèque | Usage |
|---|---|
| analyseur de configuration | gérer et analyser les fichiers de configuration |
| argparse | documentation et analyse des arguments de ligne de commande |
| demandes | interagir avec les API Web |
| lxml | lire/écrire des fichiers XML |
| json | lire/écrire des fichiers JSON |
| pyyaml | lire/écrire des fichiers YAML |
| pystache | générer des fichiers à partir de modèles |
Certains d'entre eux sont intégrés à Python 3 ; d'autres sont des modules complémentaires open source que vous pouvez inclure dans votre requirements.txt .
Cette section décrit les tests de votre package.
Une "build" complète comprenant l'exécution des tests, le peluchage ( mypy , black , flake8 , etc.) et la construction de la documentation est exécutée via :
tox
Votre projet doit avoir des tests unitaires intégrés, des tests fonctionnels, de validation, d'acceptation, etc.
Pour les tests unitaires, consultez le module unittest, intégré à Python 3.
Les objets de tests doivent se trouver dans les modules test des packages ou de préférence dans le répertoire 'tests' du projet qui reflète la structure du package du projet.
Nos tests unitaires se lancent avec la commande :
pytest
Si vous souhaitez que vos tests s'exécutent automatiquement lorsque vous apportez des modifications, démarrez pytest en mode montre avec :
ptw
Il faut utiliser le behave package et pousser les résultats des tests vers "testrail".
Voir un exemple sur https://github.com/NASA-PDS/pds-doi-service#behavioral-testing-for-integration--testing
Votre projet doit utiliser Sphinx pour créer sa documentation. Le modèle de documentation de PDS est déjà configuré dans le cadre de la version par défaut. Vous pouvez créer vos documents de projets avec :
python setup.py build_sphinx
Vous pouvez accéder aux fichiers de build dans le répertoire suivant par rapport à la racine du projet :
build/sphinx/html/
pip install wheel python setup.py sdist bdist_wheel
Les packages NASA PDS peuvent être publiés automatiquement à l'aide de Roundup Action, qui exploite les actions GitHub pour effectuer une intégration continue et une livraison continue automatisées. Un flux de travail par défaut qui inclut le Roundup est fourni dans le fichier .github/workflows/unstable-cicd.yaml . (Instable signifie ici une version intermédiaire.)
Créez le package :
python setup.py bdist_wheel
Publiez-le en tant que version Github.
Publiez sur PyPI (vous avez besoin d'un compte PyPI et configurez $HOME/.pypirc ) :
pip install twine twine upload dist/*
Ou publiez sur Test PyPI (vous avez besoin d'un compte Test PyPI et configurez $HOME/.pypirc ) :
pip install twine twine upload --repository testpypi dist/*
Le référentiel de modèles est livré avec nos deux workflows CI/CD « standard », stable-cicd et unstable-cicd . La version instable s'exécute sur n'importe quel push vers main (± en ignorant les modifications apportées à des fichiers spécifiques) et la build stable s'exécute sur la poussée d'une branche de version du formulaire release/<release version> . Ces deux éléments utilisent notre étape de création d’actions GitHub, Roundup. Le unstable-cicd générera (et mettra constamment à jour) une version SNAPSHOT. Si vous n'avez pas publié de version officielle du logiciel, vous obtiendrez une version v0.0.0-SNAPSHOT (voir NASA-PDS/roundup-action#56 pour plus de détails).
