Incluir criação e atualização de lockfile data.lock para dpm install

[fjuniorr]

O escopo desse issue é começar com uma versão simplificada em que o dpm install gera um arquivo data.lock da pasta datapackages/ usando hashdeep (as linhas de comentário devem ser excluídas antes do arquivo ser salvo):

hashdeep -l -r datapackages/
%%%% HASHDEEP-1.0
%%%% size,md5,sha256,filename
## Invoked from: /Users/fjunior/Projects/splor/painel-admin-obz EXCLUIR
## $ hashdeep -l -r datapackages/ EXCLUIR
## EXCLUIR
2139,3b7ad29d9c2f71a57b92cc94e38e4520,d3bbb69abbac324b2845bd7fa17a7a1d9cc4f6879e0df589e77ede8bb8cfef14,datapackages/teto-gastos/datapackage.json
8563,08143da84e9f6c96bfdbe57f02f9eb43,85e5ffa8dc4d79a1f06599f6a60d3f5e551933bae549481742c9e5d3971634dc,datapackages/obz-dados/datapackage.json
19176,80ffe62e66e11b095756184b38151ebe,7a854572648bab3b17e507ed756bcaa1313c0ad003b71b6640d30e63e3659697,datapackages/obz-dados/data-raw/uo_setor.xlsx
34732,764f452853fe468479585c38f92404e0,2139124807accb5490f6f611f45a3fc7b4f5e32826b70070e29c42f73db33b86,datapackages/obz-dados/data-raw/base_parecer_obz_dcmefo.xlsx
7022,2f62266d42065f83052568f65167a611,6fa45d4840e753b33db9714d7e8d3d54003b4a86e9753aa2058c7209ae2f9f21,datapackages/reestimativa/datapackage.json
127907,3f13a9b00ba807a06aa2e04fb509901d,28448c4ae0fd6eafd101fa09f9dab952b5e38832b15deb7647228915385914fa,datapackages/obz-dados/data/misc/aux_agrupamento.xlsx
602692,4b12b76370c50fc26fec310d0670aa10,49e718379ee1e38932d4668f5e522a68f6a4166ce56cad92949aa8f0a1177b56,datapackages/teto-gastos/data/exec_desp.xlsx
966370,aac68c8e1e5c07d02f817a79e9bfec4c,9f5e3c6386eab5e5620b2b2d8b230196e911672d7e656a15d67ab4c8c7f5f881,datapackages/obz-dados/data-raw/execucao_painel_obz.xlsx
3592681,445153fb56b4338d38f66f5d726abe20,b26366870291e9690df2b469d9bb12b9ae80afd71ca818ad4b45c374f751b0af,datapackages/reestimativa/data/reest_desp.csv
4403887,4a8c2e2e3b44ebc1923032e9b9a1cc30,342470ee28b6cb6850e6806d4a38aac3fd6ceae1f77c588a0f8ba82ecf65c3ff,datapackages/obz-dados/obz-dados.xlsx
5126764,05fd84bdf2a37718c0097d851f381388,a5c2e05c757218b429702d6618cfbabfc7582eb3c0f0e9eee01c095337667b88,datapackages/reestimativa/data/reest_rec.csv

Com o arquivo data.lock versionado, a gente vai ser capaz de visualizar quais arquivos foram alterados em uma dada execução do dpm install. Isso evita problemas como aquele relatado em #22.

Com isso o dpm vai passar a ter uma nova dependência de sistema, hashdeep. Faz parte do escopo pesquisar como incorporar isso no pacote da forma adequada.

[labanca]

TLDR: No momento somente criar o data.lock que vai versionar (guardar histórico) dos MD5 e SHA256 dos arquivos dos datapackages instalados.

[labanca]

Para funcionar no windows tive de baixar a versão pré-compilada md5deep-4.4.zip disponível em: https://github.com/jessek/hashdeep/releases

[fjuniorr]

Parece que o hashdeep pode alterar a ordem dos arquivos de uma execução pra outra, o que é um problema para o git

Ps. De fato não existe garantia de ordem (per https://github.com/jessek/hashdeep/issues/314). Podemos ordenar depois de capturar o output via Python para remover as linhas de comentário.

[fjuniorr]

Um dos motivos que eu gostaria de usar o hashdeep é que ele possui um audit mode que permite a verificação se houve qualquer alteração nos arquivos:

Audit mode. Each input file is compared against the set of knowns. An audit is said to pass if each input file is matched against exactly one file in set of knowns. Any collisions, new files, or missing files will make the audit fail. Using this flag alone produces a message, either "Audit passed" or "Audit Failed".

Isso seria útil para identificar divergências entre a nossa manifest file data.toml e a nossa lockile data.lock. No entanto, como primeira aproximação podemos simplesmente coletar as hashes que já estão presentes no datapackage.json.

Se possível seria interessante coletar também a hash do commit do repositório git[^1] origem dos dados para permitir uma completa reprodutibilidade via dpm install data.lock.

[^1]: O ideal seria que essa informação fosse armazenada no próprio datapackage.json, conforme discutido em https://github.com/splor-mg/ppag-planejamento-dados/issues/14, mas como o arquivo datapackage.json está sendo versionado isso não é possível.

[fjuniorr]

O nome data.lock é apenas para seguir a convenção de outras ferramentas, em termos de formato do arquivo podemos usar JSON com estrutura a ser definida durante a implementação.

[fjuniorr]

Não é exatamente a mesma coisa mas inclui no projeto acordo-judicial-reparacao-vale somente os arquivos datapackage.json da pasta datapackages/ usando um padrão especial no .gitignore e de certa forma isso diminui a prioridade desse issue.

Eu fiz isso porque o Comitê Pró-Brumadinho perguntou "Uma dúvida que surgiu aqui... Dados do relatório vão até qual data?" e o @hslinhares não seria capaz de responder a essa pergunta porque os dados estão somente na minha máquina. Com os datapackages/**/datapackage.json ele consegue.