Это прототип реализации утилиты подписи запросов для использования с бессерверным OpenSearch (AOSS). Он (на данный момент) предназначен для предоставления интерфейса в виде завитка для запроса экземпляра AOSS реестра PDS с использованием идентификатора пользователя Cognito.
В будущем могут быть реализованы дополнительные функции.
Персональные учетные данные пользователя/пароля для пользователя Cognito, авторизованного для реестра AOSS.
Питон >=3,9
Переменные среды (для получения значений обратитесь к разработчику)
экспорт REQUEST_SIGNER_AWS_ACCOUNT='' экспорт REQUEST_SIGNER_AWS_REGION='' экспорт REQUEST_SIGNER_CLIENT_ID='' экспорт REQUEST_SIGNER_USER_POOL_ID='' экспорт REQUEST_SIGNER_IDENTITY_POOL_ID='' экспорт REQUEST_SIGNER_AOSS_ENDPOINT='' экспорт REQUEST_SIGNER_COGNITO_USER='' экспорт REQUEST_SIGNER_COGNITO_PASSWORD=''
Клонировать репозиторий
git clone https://github.com/NASA-PDS/registry-client.git cd registry-client
Создайте виртуальную среду
python -m venv venv source ./venv/bin/activate
Установите инструмент в виртуальную среду
pip install --editable .[dev]
Запустите инструмент напрямую
registry-client --help
Ожидается, что все пользователи и разработчики программного обеспечения NASA-PDS будут соблюдать наш Кодекс поведения. Пожалуйста, прочтите это, чтобы убедиться, что вы понимаете ожидания нашего сообщества.
Для разработки этого проекта используйте ваш любимый текстовый редактор или интегрированную среду разработки с поддержкой Python, например PyCharm.
Для получения информации о том, как внести свой вклад в кодовые базы NASA-PDS, ознакомьтесь с нашими рекомендациями по участию.
Установите в редактируемом режиме и с дополнительными зависимостями разработчика в выбранную вами виртуальную среду:
pip install --editable '.[dev]'
Создайте базовый уровень для любых секретов (адреса электронной почты, пароли, ключи API и т. д.) в репозитории:
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
Просмотрите секреты, чтобы определить, какие из них следует разрешить, а какие являются ложными срабатываниями:
detect-secrets audit .secrets.baseline
Пожалуйста, удалите все секреты, которые не должны быть видны публике. Затем вы можете добавить базовый файл в коммит:
git add .secrets.baseline
Затем настройте перехватчики pre-commit :
pre-commit install pre-commit install -t pre-push pre-commit install -t prepare-commit-msg pre-commit install -t commit-msg
Эти перехватчики затем проверят наличие любых будущих коммитов, которые могут содержать секреты. Они также проверяют форматирование кода, соответствие PEP8, подсказки типов и т. д.
? Примечание. Требуется однократная настройка как для поддержки detect-secrets , так и для вашей глобальной конфигурации Git. Чтобы узнать, как это сделать, прочтите статью «Секреты» в вики.
Чтобы изолировать и иметь возможность воспроизвести среду для этого пакета, вам следует использовать виртуальную среду Python. Для этого запустите:
python -m venv venv
Затем используйте исключительно venv/bin/python , venv/bin/pip и т. д.
Если у вас установлен tox и вы хотите, чтобы он создал вашу среду и установил зависимости, запустите:
tox --devenv <name you'd like for env> -e dev
Зависимости для разработки указаны как dev extras_require в setup.cfg ; они устанавливаются в виртуальную среду следующим образом:
pip install --editable '.[dev]'
Весь исходный код находится в подкаталоге src .
Вам следует обновить файл setup.cfg , указав:
название вашего модуля
лицензия, Apache по умолчанию, обновление при необходимости
описание
URL-адрес загрузки, когда вы выпустите свой пакет на github, добавьте URL-адрес сюда
ключевые слова
классификаторы
install_requires, добавьте зависимости вашего пакета
extras_require, добавьте зависимости разработки вашего пакета.
точки входа: когда ваш пакет можно вызвать из командной строки, это помогает развернуть точки входа в командной строке, указывающие на сценарии в вашем пакете.
Подробности об упаковке см. в справочном документе https://packaging.python.org/tutorials/packaging-projects/.
Для управления конфигурацией удобно использовать пакет ConfigParser. Он позволяет использовать конфигурацию по умолчанию, которая может быть перезаписана пользователем в определенном файле в его среде. См. https://pymotw.com/2/ConfigParser/.
Например:
candidates = ['my_pds_module.ini', 'my_pds_module.ini.default'] found = parser.read(candidates)
Вам не следует использовать print() vin с целью регистрации информации о выполнении вашего кода. В зависимости от того, где выполняется код, эта информация может быть перенаправлена в определенные файлы журналов.
Чтобы это работало, запустите каждый файл Python с помощью:
"""Мой модуль."""import logginglogger = logging.getLogger(__name__)
Чтобы зарегистрировать сообщение:
logger.info("my message") В свой main распорядок дня включите:
logging.basicConfig(level=logging.INFO)
чтобы настроить базовую систему журналирования.
Пакет dev extras_require включенный в репозиторий шаблонов, устанавливает black , flake8 (плюс некоторые плагины) и mypy вместе с конфигурацией по умолчанию для всех из них. Вы можете запустить все это (и даже больше!) с помощью:
tox -e lint
Чтобы ваш код был читаемым, вы должны соблюдать руководство по стилю PEP8. Наш стиль кода автоматически применяется с помощью black и flake8. См. раздел «Инструменты» для получения информации о вызове конвейера проверки.
❗Важное примечание для пользователей шаблонов❗ Включенный файл конфигурации предварительной фиксации выполняет flake8 (вместе с mypy ) для всей папки src , а не только для измененных файлов. Если вы конвертируете уже существующую базу кода в этот шаблон, это может привести к множеству ошибок, с которыми вы не готовы справиться.
Вместо этого вы можете выполнить flake8 только с учетом различий текущих изменений, изменив строку entry pre-commit :
entry: git diff -u | flake8 --diff
Или вы можете изменить конфигурацию pre-commit , чтобы flake8 вызывался только для измененных файлов, которые соответствуют определенным критериям фильтрации:
- repo: local hooks: - id: flake8 name: flake8 entry: flake8 files: ^src/|tests/ language: system
Python предлагает большое разнообразие библиотек. В области PDS для самого текущего использования мы должны использовать:
| Библиотека | Использование |
|---|---|
| конфигпарсер | управлять и анализировать файлы конфигурации |
| argparse | документация и анализ аргументов командной строки |
| запросы | взаимодействовать с веб-API |
| lxml | читать/записывать XML-файлы |
| JSON | читать/записывать файлы JSON |
| пиямл | читать/записывать файлы YAML |
| фисташка | генерировать файлы из шаблонов |
Некоторые из них встроены в Python 3; другие являются надстройками с открытым исходным кодом, которые вы можете включить в свой файл requirements.txt .
В этом разделе описывается тестирование вашего пакета.
Полная «сборка», включая выполнение тестов, анализ ( mypy , black , flake8 и т. д.) и сборку документации, выполняется через:
tox
Ваш проект должен иметь встроенные модульные тесты, функциональные, проверочные, приемочные и т. д. тесты.
Для модульного тестирования воспользуйтесь модулем unittest, встроенным в Python 3.
Объекты тестов должны находиться в test модулях пакетов или, предпочтительно, в каталоге «tests» проекта, который отражает структуру пакета проекта.
Наши модульные тесты запускаются командой:
pytest
Если вы хотите, чтобы ваши тесты запускались автоматически при внесении изменений, запустите pytest в режиме просмотра с помощью:
ptw
Следует использовать behave package и отправить результаты теста в «testrail».
См. пример в https://github.com/NASA-PDS/pds-doi-service#behavioral-testing-for-integration--testing.
Ваш проект должен использовать Sphinx для создания документации. Шаблон документации PDS уже настроен как часть сборки по умолчанию. Вы можете создавать документы своих проектов с помощью:
python setup.py build_sphinx
Вы можете получить доступ к файлам сборки в следующем каталоге относительно корня проекта:
build/sphinx/html/
pip install wheel python setup.py sdist bdist_wheel
Пакеты NASA PDS можно публиковать автоматически с помощью действия Roundup Action, которое использует действия GitHub для выполнения автоматизированной непрерывной интеграции и непрерывной доставки. Рабочий процесс по умолчанию, включающий сводку новостей, представлен в файле .github/workflows/unstable-cicd.yaml . (Нестабильный здесь означает промежуточный выпуск.)
Создайте пакет:
python setup.py bdist_wheel
Опубликуйте его как выпуск Github.
Публикуйте на PyPI (вам нужна учетная запись PyPI и настройте $HOME/.pypirc ):
pip install twine twine upload dist/*
Или опубликуйте на Test PyPI (вам потребуется тестовая учетная запись PyPI и настройка $HOME/.pypirc ):
pip install twine twine upload --repository testpypi dist/*
Репозиторий шаблонов поставляется с двумя «стандартными» рабочими процессами CI/CD: stable-cicd и unstable-cicd . Нестабильная сборка запускается при любой отправке в main (± игнорируя изменения в определенных файлах), а стабильная сборка запускается при отправке ветки выпуска в форме release/<release version> . Оба они используют наш этап сборки действий GitHub Roundup. unstable-cicd создаст (и будет постоянно обновлять) выпуск SNAPSHOT. Если вы еще не выпустили официальный выпуск программного обеспечения, в конечном итоге вы получите выпуск v0.0.0-SNAPSHOT (подробности см. в NASA-PDS/roundup-action#56).
