Bug ocorre na função fetch_votos() ao percorrer o loop e tentar pegar a última página. Como a última página (5) é vazia, ele não consegue retornar isso como um dataframe e retorna uma lista vazia e gera um erro no dplyr::do

Esse código deve ir para o repo do QMR, já que o dataframe criado é específico para o QMR. Sugiro tirar inclusive da vignette de introdução.

Mudar nossa documentação das funções públicas ao menos para o ROxygen, e incluir sempre uma diretiva @example, além de @references para a documentação da câmara.

Bons exemplos:

https://github.com/hadley/ggplot2movies/blob/master/R/movies.R

https://github.com/tidyverse/dplyr/blob/master/R/nth-value.R

Seria legal ter a função para recuperar os deputados baseada nesse serviço: https://dadosabertos.camara.leg.br/api/v2/deputados

Obs.: o serviço é paginado.

Esse vignette não deve mais usar o script R linha de comando. Ele pode usar o exemplo com purrr que sugeri. E o nome dele não precisa fazer referência ao QMR.

https://analytics-ufcg.edu.br/rcongresso

Gerar site no /docs e hospedá-lo via github pages usando o pkgdown: https://github.com/hadley/pkgdown

Atualmente nenhuma proposição do tipo "REQ" está sendo encontrada na API e algumas outras estão faltando. A mensagem de erro retornada é:

Erro: Column `id` must be a 1d atomic vector or a list
Execução interrompida

caso não seja encontrada alguma proposição passada no arquivo e isso interrompe a execução do programa, mas não indica qual proposição que retornou o erro.

Comportamento esperado:

Poder utilizar os parâmetros tal qual ocorre na API a fim de filtrar a busca.

Comportamento real:

A busca é limitada apenas aos últimos 6 meses de gasto de determinado deputado.

Comportamento esperado:

Ao não se ter deputados na câmara nesse período que os eleitos desse ano irão assumir o cargo, era esperado que os testes não dessem erro esperando que existam deputados sempre.

Comportamento real:

Os testes estão dando erros porque a API não está retornando deputados por enquanto.

Passos para reproduzir o erro:

devtools::test()

Versão do Sistema Operacional e do R:

Ubuntu 16.04
R version 3.5.0

https://cran.r-project.org/web/packages/httr/vignettes/api-packages.html

Comportamento esperado:

Do vignette sobre purrr + rcongresso, esperava achar as votações que aparecem no exemplo.

Comportamento real:

> fetch_votacoes(14493)
Error in .get_from_api(path, query) : Not Found (HTTP 404).
> fetch_votacoes(351362)
Error in .get_from_api(path, query) : Not Found (HTTP 404).

Passos para reproduzir o erro:

Rodar o vignette.

Versão do Sistema Operacional e do R:

Erro nos testes devido à mudança de posição nas colunas, o que gera um erro nos testes, na comparação.

Explicar que quando usamos id não faz sentido usar as demais.

Explicar como recuperar todas as proposições que satisfazem os critérios - atualmente parece que o máximo é 100.

Queremos mesmo expor o parâmetro pagina? Acho que não.

O que é codPartido ?

Qual o formato das datas?

Talvez uma pequena vignette ajude?

Comportamento esperado:

1. Dado um deputado retornar todas as votações do mesmo, incluindo data.
2. Dado um intervalo de data retornar todas as votações de todos os deputados.

Comportamento real:

Há um limite de votações retornadas.

Comportamento esperado:

Ponderar entre lançar um erro na tela ou um warning e retornar NULL para o caso de não encontrado.

Motivos: Uma lista muito grande de proposições, por exemplo, e na última esse erro 404 ser gerado... A lista inteira será perdida e o usuário terá que executar a função novamente. Isso pode ser muito custoso (e frustrante).

Comportamento real:

O erro estoura.

Utilizar o lintr para verificar se o código segue o estilo sugerido pelo tidyverse.

para a v0.2, seria muito útil ter essa função, baseada no endpoint /proposicoes

Para não mencionar QMR e dizer o que ela faz.

A prática mais comum em R é ter nomes todos minúsculos, assim, sugiro que em vez de library(Rcongresso) o usuário faça library(rcongresso)

Ao executar o comando

library(rcongresso)
vignette("quem-me-representa", package="rcongresso")

o seguinte erro é gerado:

Warning message:
vignette ‘quem-me-representa’ not found 

Algumas endpoints da API, após atualizações, aceitam uma lista de ids. A ideia é eliminar essa consulta de 1 id por vez e substituir pela consulta utilizando as listas.

Sugestões:

• Nomes em pt-br
• Sempre que o código for buscar algo na API, ser fetch_algumacoisa.

Mensagem da equipe do CRAN:

We also get:
License components with restrictions and base license permitting such:
  GPL-3 + file LICENSE
File 'LICENSE':
                     GNU LESSER GENERAL PUBLIC LICENSE
                         Version 3, 29 June 2007
                                        ....

The license file should only contain addiotinal restrictions, not the full licnese.


Please write the title in title case.

Tornar os testes dos data frames resultantes mais genéricos a fim de não haver quebra nos testes sempre que houver uma mudança nestes.

Atualmente, aparentemente, se der um fetch_tramitacao com um vetor de IDs em que algum valor é repetido dá erro 404.

Parece ser fácil de resolver o problema, apenas passando por um unique.

Minha questão é se esse unique deveria ser feito pela RCongresso, ou se a mensagem de erro deveria ser mais descritiva.

É provável que o mesmo problema afete outras funções da lib.

Passos para reproduzir o erro:

fetch_tramitacao(c("2175303", "2175303"))
Error: Falha na requisicao a API dos Dados Abertos. Erro 404 ao tentar acessar: > https://dadosabertos.camara.leg.br/api/v2/proposicoes/2175303/tramitacoes/api/v2/proposicoes/2175303/tramitacoes

Versão do Sistema Operacional e do R:

Arch Linux - R version 3.5.0

Error in prop_types %>% filter(prop_types$id == proposicao$idTipo) :não foi possível encontrar a função "%>%"

Erro gerado ao rodar o script de testes. Deve ser o mesmo problema para o #1, algum import ou referência que estava faltando.

Nossa licença (como dito no repo) é LGPL 3.0. No site gerado pelo pkgdown está como MIT + Licence. Parece vir do DESCRIPTION, linha 13: License: MIT + file LICENSE

Comportamento esperado:

Que na documentação esteja especificado o retorno de todos os itens ao passar -1 como parâmetro.

Esse erro ocorre devido à um bug na API da Câmara. Existe um campo do json chamado links que apontam para próxima página para recuperar os próximos 100 itens. O href next aponta para um endereço inexistente e ao fazer o GET, nenhum json é recuperado. Ao fazer a comparação nas linhas seguintes o erro é gerado.

Essa versão se encontra na branch get-all-voters para não interferir na função atual que captura os 100 primeiros deputados votantes.

Termos como proposições, por exemplo, estão incorretos na tradução de forma que seria bom revisar toda a documentação.

Um ou dois estilo:

fetch_id_proposicao(tipo = "PL",
                    numero = 1057, 
                    ano = 2007) %>% 
  fetch_proposicao(id) %>% 
  fetch_votacoes(id) %>% 
  ultima_votacao() %>% 
  fetch_votacao(id)

de preferência com a entrada inicial vetorizada, como

fetch_id_proposicao(tipo   = c("PEC", "PL"), 
                    numero = c(171, 1057),
                    ano    = c(1993, 2007)) %>% 
...

Os testes atuais não cobrem o comportamento das funções usando as queries.

Comportamento esperado:

Backoff exponencial fazendo retry até que se consiga uma resposta do lado do servidor.

Comportamento real:

O pacote desiste na primeira tentativa

Comportamento esperado:

Que exista funções que cubram os endpoints /blocos e /blocos/{id}

Ao fazer:

curl -X GET "https://dadosabertos.camara.leg.br/api/v2/deputados/178957" -H  "accept: application/json"

que deveria retornar os dados do deputado Abel Salvador Mesquita Júnior, retorna agora erro 404.

Isso se deve a um novo modelo de acesso aos dados do deputado, que deve ser feito dessa forma:

https://dadosabertos.camara.leg.br/api/v2/deputados?id=178957

Embora essa solução acesse os dados dos deputados, alguns campos estão faltando, tais quais: sexo, data de nascimento, uf de nascimento, municipio de nascimento, cpf e escolaridade - disponíveis anteriormente. Além disso, um objeto chamado ultimoStatus contendo informações mais recentes sobre a atuação do deputado também está faltando ao fazer a chamada por esse método.

Comportamento esperado:

Resposta entre 1 e 2 segundos, no máximo 30 segundos.

Comportamento real:

O sistema fica lento ao fazer requisições muito grandes, passando de 2 a 3 minutos para retornar um data frame pequeno de 500 linhas.

Passos para reproduzir o erro:

Utilizar qualquer função. Mas, especificamente a função fetch_ultimo_status_deputado() está demorando bastante para responder.

Solução: Procurar uma solução mais eficiente para a varredura linear das colunas que buscam por elementos nulos e listas. Pode ser que haja outros problemas também influenciando na performance do sistema.

Oi, @paul0vinicius !

A API da Câmara sofreu mudanças e isso parece ter quebrado vários dos testes aqui da RCongresso (falo pela experiência que tivemos no fork em que estamos trabalhando).
Já estamos com um PR que arruma esses problemas, mas ele está misturado com outros código das alterações que estamos fazendo na RCongresso como um todo.
Dai não sei o que vc prefere, se já começamos a colocar todas as nossas alterações aqui, ou se vc quer tentar extrair do PR só o que corrige esses erros.

Mensagem da equipe do CRAN:

Thanks, please write all package informations (DESCRIPTION file, Rd-files, ...) in English.

Please fix and resubmit.

Comportamento esperado:

Os partidos deveriam estar associados à uma orientação, bancada e ao ID da votação.

Comportamento real:

Os nomes dos partidos estão corrompidos. O erro é no REGEX que não está cobrindo todos os casos para extrair corretamente o partido a partir da bancada associada.

Passos para reproduzir o erro:

Basta utilizar a função, por exemplo:

get_votos_partidos(7252)

Por exemplo, em get_proposition(i), i deve poder ser um vetor de proposições. Como em R todo objeto é um vetor, é boa prática que as funções saibam operar sobre vetores.

Devido à atualização na API, essa função precisa ser repensada. Os campos dataInicio e dataFim do endpoint /proposicoes parece ser obrigatório, não sendo mais possível recuperar o ID da proposição utilizando apenas a sigla do tipo, ano e número.

Comportamento esperado:

Ao ocorrer erros do tipo 500, deve-se aguardar o backoff exponencial, senão, deve-se pular o teste no CRAN por se tratar de erro na API.

Comportamento real:

O teste se torna dependente do status da API

Ao recuperar os dados da API, ela retorna os dados do partido atual e não o do partido cuja data da votação fora realizada.

Por exemplo, nos votos da PEC171 da votação ocorrida no dia 30/06/2015, a deputada Luiza Erundina era filiada ao partido PSB. Porém, ao fazer uma consulta dos votos utilizando a API ele retorna que a candidata era filiada ao PSOL. Eu acho que por baixo dos panos, a API faz uma consulta direta usando a função para pegar os detalhes de um deputado e joga partido atual como se fosse o da época em que a votação ocorreu.