Closed fjuniorr closed 2 months ago
No entanto nesse formato somente é possível gerar os arquivos de dados dos recursos normalizados.
Ou podemos simplesmente adicionar uma flag --metadata-dir
e o arquivo de metadado apropriado (seja um data package, data resource, ou table schema controlado com --type
) seria gerado também. --no-metadata-dir
não geraria metadados e --yaml
e --json
altera o formato de serialização.
Ontem enquanto estava criando os parâmetros --json
e --yaml
fiquei muito tempo tentando fazer com que esses parametros fossem uma lista de parâmetros, todos vinculados a uma só variável-parâmetro, algo como:
metadata_format: Annotated[[str], typer.Option("--yaml", "--json")] = "--json",
O código acima não funciona. Mas a idéia é que quando o dpm build
se passar a gerar recursos em vários formatos diferentes (xlsx, txt, csv, zip, gz, etc), uma lista muito extensiva de opções no help talvez fosse inconveniente.
Não acho que a gente perde usabilidade em usar algo como:
dpm build --format xlsx
Seguindo na ideia https://github.com/splor-mg/cookiecutter-datapackage/issues/27 um possível comando seria:
Para utilizar no cookiecutter seria necessário algo como:
No entanto nesse formato somente é possível gerar os arquivos de dados dos recursos normalizados. Isso significa que seria necessário alguma forma de chamar o comando para produzir somente os metadados a partir dos arquivos de dados normalizados como ocorre hoje com o build.