Esta é uma implementação de protótipo de um utilitário de assinatura de solicitação para uso com OpenSearch sem servidor (AOSS). (Atualmente) pretende fornecer uma interface semelhante a curl para consultar a instância AOSS do PDS Registry usando uma identidade de usuário Cognito.
Funcionalidades adicionais podem ser desenvolvidas no futuro.
Credenciais pessoais de usuário/senha para um usuário Cognito autorizado para Registry AOSS
Pitão >=3.9
Variáveis de ambiente (entre em contato com o desenvolvedor para obter 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 o repositório
git clone https://github.com/NASA-PDS/registry-client.git cd registry-client
Crie um ambiente virtual
python -m venv venv source ./venv/bin/activate
Instale a ferramenta no ambiente virtual
pip install --editable .[dev]
Execute a ferramenta diretamente
registry-client --help
Espera-se que todos os usuários e desenvolvedores do software NASA-PDS cumpram nosso Código de Conduta. Por favor, leia isto para garantir que você entende as expectativas de nossa comunidade.
Para desenvolver este projeto, utilize seu editor de texto preferido, ou um ambiente de desenvolvimento integrado com suporte Python, como o PyCharm.
Para obter informações sobre como contribuir com as bases de código NASA-PDS, dê uma olhada em nossas diretrizes de contribuição.
Instale em modo editável e com dependências extras de desenvolvedor no ambiente virtual de sua escolha:
pip install --editable '.[dev]'
Faça uma linha de base para quaisquer segredos (endereços de e-mail, senhas, chaves de API, etc.) no repositório:
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 os segredos para determinar quais devem ser permitidos e quais são falsos positivos:
detect-secrets audit .secrets.baseline
Remova quaisquer segredos que não devam ser vistos pelo público. Você pode então adicionar o arquivo de linha de base ao commit:
git add .secrets.baseline
Em seguida, configure os 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
Esses ganchos verificarão quaisquer commits futuros que possam conter segredos. Eles também verificam a formatação do código, conformidade com PEP8, dicas de tipo, etc.
? Observação: uma configuração única é necessária para dar suporte detect-secrets e na configuração global do Git. Veja a entrada do wiki em Secrets para saber como.
Para isolar e poder reproduzir o ambiente deste pacote, você deve usar um Ambiente Virtual Python. Para fazer isso, execute:
python -m venv venv
Em seguida, use exclusivamente venv/bin/python , venv/bin/pip , etc.
Se você tem tox instalado e gostaria que ele criasse seu ambiente e instalasse dependências para você execute:
tox --devenv <name you'd like for env> -e dev
As dependências para desenvolvimento são especificadas como dev extras_require em setup.cfg ; eles são instalados no ambiente virtual da seguinte forma:
pip install --editable '.[dev]'
Todo o código-fonte está em um subdiretório em src .
Você deve atualizar o arquivo setup.cfg com:
nome do seu módulo
licença, apache padrão, atualize se necessário
descrição
url de download, quando você liberar seu pacote no github adicione o url aqui
palavras-chave
classificadores
install_requires, adicione as dependências do seu pacote
extras_require, adicione as dependências de desenvolvimento do seu pacote
entry_points, quando seu pacote pode ser chamado na linha de comando, isso ajuda a implantar pontos de entrada de linhas de comando apontando para scripts em seu pacote
Para obter detalhes do pacote, consulte https://packaging.python.org/tutorials/packaging-projects/ como referência.
É conveniente usar o pacote ConfigParser para gerenciar a configuração. Permite uma configuração padrão que pode ser sobrescrita pelo usuário em um arquivo específico em seu ambiente. Consulte https://pymotw.com/2/ConfigParser/
Por exemplo:
candidates = ['my_pds_module.ini', 'my_pds_module.ini.default'] found = parser.read(candidates)
Você não deve usar print() com o objetivo de registrar informações sobre a execução do seu código. Dependendo de onde o código é executado, essas informações podem ser redirecionadas para arquivos de log específicos.
Para fazer isso funcionar, inicie cada arquivo Python com:
"""Meu módulo."""import logginglogger = logging.getLogger(__name__)
Para registrar uma mensagem:
logger.info("my message") Na sua rotina main , inclua:
logging.basicConfig(level=logging.INFO)
para configurar um sistema de registro básico.
O dev extras_require incluído no repositório de modelos instala black , flake8 (mais alguns plugins) e mypy junto com a configuração padrão para todos eles. Você pode executar tudo isso (e muito mais!) com:
tox -e lint
Para que seu código seja legível, você deve seguir o guia de estilo PEP8. Nosso estilo de código é aplicado automaticamente via black e flake8. Consulte a seção Ferramentas para obter informações sobre como invocar o pipeline linting.
❗Nota importante para usuários de modelos❗ O arquivo de configuração pré-commit incluído executa flake8 (junto com mypy ) em toda a pasta src e não apenas nos arquivos alterados. Se você estiver convertendo uma base de código pré-existente para este modelo, isso poderá resultar em muitos erros com os quais você não está pronto para lidar.
Em vez disso, você pode executar flake8 apenas sobre uma comparação das alterações atuais que estão sendo feitas, modificando a linha entry pre-commit :
entry: git diff -u | flake8 --diff
Ou você pode alterar a configuração pre-commit para que flake8 seja chamado apenas em arquivos alterados que correspondam a determinados critérios de filtragem:
- repo: local hooks: - id: flake8 name: flake8 entry: flake8 files: ^src/|tests/ language: system
Python oferece uma grande variedade de bibliotecas. No escopo do PDS, para o uso mais atual devemos usar:
| Biblioteca | Uso |
|---|---|
| analisador de configuração | gerenciar e analisar arquivos de configuração |
| argparse | documentação e análise de argumentos de linha de comando |
| solicitações | interagir com APIs da web |
| lxml | ler/escrever arquivos XML |
| json | ler/gravar arquivos JSON |
| pyyaml | ler/gravar arquivos YAML |
| pistache | gerar arquivos a partir de modelos |
Alguns deles estão integrados ao Python 3; outros são complementos de código aberto que você pode incluir em seu requirements.txt .
Esta seção descreve os testes do seu pacote.
Uma "construção" completa, incluindo execução de teste, linting ( mypy , black , flake8 , etc.) e compilação de documentação é executada via:
tox
Seu projeto deve ter testes de unidade integrados, testes funcionais, de validação, de aceitação, etc.
Para testes unitários, confira o módulo unittest, integrado ao Python 3.
Os objetos de testes devem estar em pacotes de módulos test ou preferencialmente no diretório 'testes' do projeto que reflete a estrutura do pacote do projeto.
Nossos testes unitários são iniciados com o comando:
pytest
Se você deseja que seus testes sejam executados automaticamente conforme você faz alterações, inicie pytest no modo de observação com:
ptw
Deve-se usar o behave package e enviar os resultados do teste para "testrail".
Veja um exemplo em https://github.com/NASA-PDS/pds-doi-service#behavioral-testing-for-integration--testing
Seu projeto deve usar o Sphinx para construir sua documentação. O modelo de documentação do PDS já está configurado como parte da compilação padrão. Você pode criar documentos de seus projetos com:
python setup.py build_sphinx
Você pode acessar os arquivos de construção no seguinte diretório relativo à raiz do projeto:
build/sphinx/html/
pip install wheel python setup.py sdist bdist_wheel
Os pacotes PDS da NASA podem ser publicados automaticamente usando o Roundup Action, que aproveita o GitHub Actions para realizar integração contínua automatizada e entrega contínua. Um fluxo de trabalho padrão que inclui o Roundup é fornecido no arquivo .github/workflows/unstable-cicd.yaml . (Instável aqui significa uma versão provisória.)
Crie o pacote:
python setup.py bdist_wheel
Publique-o como uma versão do Github.
Publique no PyPI (você precisa de uma conta PyPI e configure $HOME/.pypirc ):
pip install twine twine upload dist/*
Ou publique no Test PyPI (você precisa de uma conta Test PyPI e configure $HOME/.pypirc ):
pip install twine twine upload --repository testpypi dist/*
O repositório de modelos vem com nossos dois fluxos de trabalho CI/CD "padrão", stable-cicd e unstable-cicd . A compilação instável é executada em qualquer push para main (± ignorando alterações em arquivos específicos) e a compilação estável é executada em push de uma ramificação de lançamento no formato release/<release version> . Ambos fazem uso de nossa etapa de construção de ações do GitHub, Roundup. O unstable-cicd irá gerar (e atualizar constantemente) uma versão SNAPSHOT. Se você não fez uma versão formal do software, você terminará com uma versão v0.0.0-SNAPSHOT (consulte NASA-PDS/roundup-action#56 para obter detalhes).
