Nltk: Falha ao baixar dados NLTK: HTTP ERROR 405/403

Criado em 26 jul. 2017  ·  47Comentários  ·  Fonte: nltk/nltk

>>> nltk.download("all")
[nltk_data] Error loading all: HTTP Error 405: Not allowed.

>>> nltk.version_info
sys.version_info(major=3, minor=5, micro=2, releaselevel='final', serial=0)

Além disso, tentei visitar https://raw.githubusercontent.com/nltk/nltk_data/gh-pages/packages/corpora/cmudict.zip . Obteve o mesmo erro HTTP 405.

Encontre o mesmo problema em stackoverflow: https://stackoverflow.com/questions/45318066/getting-405-while-trying-to-download-nltk-dta

Quaisquer comentários serão apreciados.

admin bug corpus inactive

Comentários muito úteis

@plaihonen você deve ser capaz de usar este índice alternativo fazendo algo como python -m nltk.downloader -u https://pastebin.com/raw/D3TBY4Mj punkt

Todos 47 comentários

Parece que o Github está desativando / bloqueando o acesso ao conteúdo bruto no repo.

Enquanto isso, a solução temporária é mais ou menos assim:

PATH_TO_NLTK_DATA=/home/username/nltk_data/
wget https://github.com/nltk/nltk_data/archive/gh-pages.zip
unzip gh-pages.zip
mv nltk_data-gh-pages/ $PATH_TO_NLTK_DATA

Atualmente, baixar o gh-pages.zip e substituir o diretório nltk_data é a solução de trabalho por enquanto.

Antes de encontrarmos em outro canal para distribuir nltk_data , use a solução acima.


~ Estranhamente, parece afetar apenas a conta de usuário nltk . Funciona bem na bifurcação: https://raw.githubusercontent.com/alvations/nltk_data/gh-pages/index.xml~

~ Fazer isso também funcionaria: ~

@alvations Muito obrigado!

Existe alguma alternativa para os downloads de linha de comando como este?
python -m nltk.downloader -d ./nltk_data punkt

@plaihonen você deve ser capaz de usar este índice alternativo fazendo algo como python -m nltk.downloader -u https://pastebin.com/raw/D3TBY4Mj punkt

@rvause Funciona perfeitamente. Obrigado!

+1. esta foi uma surpresa de várias horas esta manhã. Foi ignorando completamente o download nltk por enquanto

O GitHub está bloqueando o acesso porque "um usuário está consumindo uma grande quantidade de arquivos de solicitação de largura de banda". Eles também sugeriram que devemos olhar para uma maneira diferente de distribuir pacotes de dados, por exemplo, S3.

Mesmo com índice alternativo, alguém descobriu que alguns pacotes ainda não funcionam?

Especificamente, para mim, o pacote de stopwords me dá um 405, os outros (brown, wordnet, punkt, etc) não.

sim, também não consigo baixar as palavras irrelevantes do nltk. Recebo o erro 405 quando faço> python -m nltk.downloader -u http://nltk.github.com/nltk_data/

Ei, estou tentando executar python -m nltk.downloader stopwords , mas estou recebendo o erro 405. Alguém pode me apontar na direção certa?

@ dfridman1 @ prakruthi-karuna leia a edição acima. A solução é:

python -m nltk.downloader -u https://pastebin.com/raw/D3TBY4Mj all

Temos alguns projetos usando isso em nosso sistema ci. Em vez de ter que atualizar todos eles com o parâmetro -u, há outra maneira de especificar esses dados. Talvez uma variável de ambiente ou arquivo de configuração?

@alvations , parece que sua solução não funciona mais, pois a versão bifurcada agora também é proibida. Alguém está atualmente em contato com o suporte do github sobre isso?

>>> import nltk
>>> dler = nltk.downloader.Downloader('https://pastebin.com/raw/D3TBY4Mj')
>>> dler.download('punkt')
[nltk_data] Downloading package punkt to /home/zeryx/nltk_data...
[nltk_data] Error downloading u'punkt' from
[nltk_data]     <https://raw.githubusercontent.com/alvations/nltk_data
[nltk_data]     /gh-pages/packages/tokenizers/punkt.zip>:   HTTP Error
[nltk_data]     403: Forbidden.
False

Acabei de abrir um tíquete com eles através da página de contato.

Parece que o GitHub está ciente e trabalhando no problema. Aqui está o que eles me disseram:

Desculpe o incómodo. Tivemos que bloquear solicitações de URLs raw.githubusercontent.com para o repositório nltk / nltk_data e seus bifurcações porque o uso excessivo estava causando problemas com o serviço GitHub. Estamos trabalhando para resolver o problema, mas infelizmente não podemos permitir essas solicitações no momento.

Sim, também acabei de receber:

Oi Liling,
Trabalho na equipe de suporte do GitHub e gostaria de notificá-lo de que tivemos que bloquear temporariamente o acesso aos arquivos servidos em raw.githubusercontent.comURLs para o repo alvations / nltk_data. Atualmente, um usuário está consumindo uma grande quantidade de largura de banda solicitando arquivos desse repo e nossa única opção no momento é bloquear todas as solicitações. Estamos trabalhando ativamente para encontrar maneiras de mitigar o problema e entraremos em contato com você quando tivermos uma atualização. Informe-nos se tiver alguma dúvida.
Saúde, Shawna

@ ewan-klein @stevenbird Acho que precisamos de uma nova maneira de distribuir dados, mas isso vai exigir um retrabalho do nltk.downloader.py .

Algumas sugestões:

Aparentemente, não temos escolha a não ser mudar o canal de distribuição de dados:

Oi Liling,
Desejo dar seguimento a isso com algumas informações adicionais. Discutimos o problema internamente e é altamente provável que não restauremos o acesso bruto aos repositórios na rede de bifurcações nltk / nltk_data em um futuro previsível. O problema é que várias máquinas estão chamando nltk.download () em uma frequência muito alta. Não podemos restaurar o acesso bruto até que a atividade pare. Sinta-se à vontade para compartilhar esta mensagem com a comunidade nltk. Esperamos que quem está fazendo isso seja alertado sobre o problema e pare qualquer processo que esteja fazendo isso.
Saúde, Jamie

Alguém poderia pensar que eles poderiam simplesmente bloquear esses IPs especificamente. Mas talvez haja mais do que isso.

Eu tenho uma imagem docker que baixa nltk_data, mas eu não a estava reconstruindo com frequência. Espero não ser um daqueles usuários de alto tráfego ...

Existe um processo de instalação que não depende do github?

Talvez alguém tenha configurado seus scripts na AWS de forma incorreta. @todos, por favor ajude a verificar suas instâncias enquanto encontramos uma alternativa para distribuição de dados

Oi Liling,
Não podemos compartilhar números específicos, no entanto, as solicitações vêm de um grande número de instâncias da AWS. Suspeitamos que pode ser um script ou processo de construção que deu errado. Não sabemos muito além disso.
Saúde, Jamie

Bem, isso é um alívio, eu não uso AWS.

:aliviado:

Em termos de código, talvez tenhamos que mudar a frequência com que o mesmo pacote é atualizado a partir de nltk downloader.py também. Caso contrário, independentemente do canal de distribuição para o qual migramos, a mesma interrupção do serviço acontecerá.

Talvez algo baseado em torrent funcionasse?

Não tenho certeza de como é a licença, mas você pode torná-la pública no s3: https://aws.amazon.com/datasets/

@alvations parece que apenas o download do gzip funciona por enquanto. E os pacotes precisavam ser movidos /home/username/nltk_data/ pasta

export PATH_TO_NLTK_DATA=/home/username/nltk_data/
wget https://github.com/nltk/nltk_data/archive/gh-pages.zip
unzip gh-pages.zip
mv nltk_data-gh-pages $PATH_TO_NLTK_DATA
# add below code
mv $PATH_TO_NLTK_DATA/nltk_data-gh-pages/packages/* $PATH_TO_NLTK_DATA/

Ainda temos uma solução temporária?

@darshanlol @alvations mencionou uma solução. Se você está tentando construir um docker, o seguinte funcionou para mim:

ENV PATH_TO_NLTK_DATA $HOME/nltk_data/
RUN apt-get -qq update
RUN apt-get -qq -y install wget
RUN wget https://github.com/nltk/nltk_data/archive/gh-pages.zip
RUN apt-get -y install unzip
RUN unzip gh-pages.zip -d $PATH_TO_NLTK_DATA
# add below code
RUN mv $PATH_TO_NLTK_DATA/nltk_data-gh-pages/packages/* $PATH_TO_NLTK_DATA/

Tento alterar o url padrão em 'nltk.downloader.py'.Mas o problema ainda existe.

A solução alternativa sugerida não está mais funcionando:

python -m nltk.downloader -u https://pastebin.com/raw/D3TBY4Mj all

Atualmente, esta é a única solução de trabalho:

PATH_TO_NLTK_DATA=/home/username/nltk_data/
wget https://github.com/nltk/nltk_data/archive/gh-pages.zip
unzip gh-pages.zip
mv nltk_data-gh-pages/ $PATH_TO_NLTK_DATA

Como @alvations disse, esta é a única solução que funciona.

PATH_TO_NLTK_DATA = / home / username / nltk_data /wget https://github.com/nltk/nltk_data/archive/gh-pages.zipdescompacte gh-pages.zipmv nltk_data-gh-pages / $ PATH_TO_NLTK_DATA

Mas mesmo depois de baixar todas as páginas, eu estava enfrentando problemas, pois meu downloader NLTK não foi capaz de detectar todos os pacotes baixados para isso, você pode ter que alterar manualmente o valor do diretório de download através do comando.

Esta página tem o comando adequado que usei para configurar pacotes de dados NLTK

Clique no link acima para responder.

Aqui estão algumas propostas para resolver esse problema depois de ler e encontrar alternativas.

Tornar corpora pipable

  • Primeiro, vamos alterá-lo de forma que todos os nltk_data possam ser pipocados. (Assim, cada novo ambiente exigirá uma nova instalação de pip e não dependemos mais do diretório físico)
  • Teremos de manter o controle de algum tipo de índice também para o download buscar e rastrear versões.
  • Então, também precisamos ter algum tipo de revisão no código, o downloader.py e toda a interface do leitor de corpus relacionado

  • Possivelmente limitações de pip (do lado PyPI) podem parar os usuários / máquinas desonestos com solicitações de alta frequência

Hospedando os dados no S3 / Zenodo ou algum host privado

Isso exigiria simplesmente vincular novamente os links no index.xml aos links apropriados. Depois de configurar os arquivos individuais no host da web.

Mas se o tráfego permanecer alto devido a algum script de instalação / automação que deu errado, acabamos grampeando um provedor de serviço para outro.


Alguma outra sugestão?
Alguma alma corajosa que queira enfrentar isso?

@ harigovind511 , sim, você deve colocar a pasta nltk_data baixada em um dos locais padrão onde o nltk sabe que deve procurá-la ou adicionar nltk.data.path para dizer onde procurar. O downloader automático procura apenas um local padrão.

A limitação / resolução de taxa para máquinas desonestas é provavelmente necessária para fazer com que isso não volte a aparecer. Meu voto seria a favor do pip, a menos que haja algum problema (ou tabu) com pacotes grandes no pip?

Usar o pip também resolveria o nltk.download () manual e o gerenciamento de pacotes no código.

Os arquivos parecem estar de volta? Porém, parece sensato continuar a buscar mecanismos alternativos de distribuição. Na minha própria organização, planejamos mudar para hospedagem interna e fazer check-in trimestral

Eu gostaria de entender o que $ PATH_TO_NLTK_DATA faz. Ele está configurando um URL de download local alternativo para onde o NLTK obtém seus dados?

Gostaria de configurar um cache local de dados NLTK, então gostaria de saber se essa configuração informa ao NLTK para trabalhar offline.

Uma vez que a raiz do problema é o abuso de largura de banda, parece uma ideia ruim recomendar a busca manual de toda a árvore nltk_data como uma solução alternativa. Que tal você nos mostrar como os IDs de recursos mapeiam para URLs, @alvations , para que eu possa wget apenas o pacote punkt , por exemplo?

A solução de longo prazo, eu acredito, é tornar menos trivial para usuários iniciantes buscarem todo o pacote de dados (638 MB compactados, quando eu verifiquei). Em vez de organizar (e pagar por) mais largura de banda para desperdiçar em downloads inúteis, pare de fornecer "all" como opção de download; em vez disso, a documentação deve mostrar ao criador de scripts desatento como baixar os recursos específicos de que precisam. E enquanto isso, saia do hábito de escrever nltk.download("all") (ou equivalente) como amostra ou uso recomendado, no stackoverflow (estou olhando para você, @alvations) e nas docstrings do downloader. (Para explorar o nltk, nltk.dowload("book") , não "all" , é igualmente útil e muito menor.)

No momento, é difícil descobrir qual recurso precisa ser baixado; se eu instalar o nltk e experimentar nltk.pos_tag(["hello", "friend"]) , não há como mapear a mensagem de erro para um ID de recurso que posso passar para nltk.download(<resource id>) . Baixar tudo é a solução óbvia nesses casos. Se nltk.data.load() ou nltk.data.find() puderem ser corrigidos para pesquisar a identificação do recurso nesses casos, acho que você verá seu uso em nltk_data diminuir significativamente a longo prazo.

@zxiiro $PATH_TO_NLTK_DATA não tem significado para o nltk, é apenas uma variável no script de amostra. A variável de ambiente $NLTK_DATA tem um significado especial. Veja http://www.nltk.org/data.html , todas as opções são explicadas.

@alexisdimi concordou com nltk.download('all') . Desculpe, essa era uma resposta tão antiga dos meus primeiros dias. Eu deveria aconselhar contra isso. Em vez disso, mudei a resposta do SO para nltk.download('popular') : https://stackoverflow.com/questions/22211525/how-do-i-download-nltk-data

Um dos problemas com wget diretamente em um pacote é que ele ainda depende do conteúdo bruto do github. Durante o tempo de inatividade, o link https://github.com/nltk/nltk_data/blob/gh-pages/packages/tokenizers/punkt.zip também estava levando ao erro 403/405.

Assim, a solução foi baixar toda a árvore git. Em retrospecto, isso pode não ser uma boa ideia.

Parece que o bloqueio foi cancelado, ótimo! Agora espero que haja alguns tíquetes que ajudem a prevenir problemas semelhantes no futuro (talvez ao longo das linhas que sugeri, talvez não).

(A propósito, _este_ problema deve ser marcado como "Fechado", agora que os downloads voltaram a funcionar?)

@alexisdimi colocar avisos que sugiram que os usuários

Para aqueles que executam NLTK em um ambiente de CI. Eu gostaria de propor GH-1795 que permite o uso para especificar um URL alternativo para download. A ideia aqui é que pode-se configurar uma cópia local de nltk_data em um servidor web (ou mesmo python -m http.server) e então ter uma variável global que pode sobrescrever a URL de download.

Isso é para que possamos substituir, sem modificar as chamadas de comando local do projeto para incluir -u de um sistema de CI como o Jenkins.

Pergunta para o Github sobre distribuição de dados pip usando versões e instalação pip:

Obrigado Jamie pelo apoio!

Estamos procurando alternativas para hospedar o nltk_data e uma delas é hospedá-los como lançamentos de repositório, como o SpaCy faz isso https://github.com/explosion/spacy-models/releases

Podemos apenas verificar com você se o mesmo bloco será executado se solicitações semelhantes de alta frequência forem feitas para as versões do repositório? Ou as versões do repositório são tratadas de forma diferente do conteúdo bruto no Github?

Saudações,
Liling

Algumas atualizações no lado do Github:

Oi Liling,

Usar Releases apenas move as solicitações para uma parte diferente de nossa infraestrutura. Se esse volume de largura de banda fosse reiniciado, ainda teríamos que bloquear essas solicitações, mesmo que fossem para Releases.

Tentamos pensar em algumas maneiras de os pacotes de dados permanecerem no GitHub, mas honestamente não há uma boa solução. Não estamos configurados para ser um CDN de alto volume.

Felicidades,
Jamie

@owaaa / @zxiiro +1 em hospedagem interna para CI. Estamos fazendo isso agora, e a vantagem para os usuários do EC2 / S3 é que você pode colocar os dados (ou o subconjunto deles de que precisa) perto de onde deseja construir as máquinas. Se você estiver em zonas de disponibilidade, pode simplesmente replicar buckets onde você precisa e ser mais robusto para o que está acontecendo fora da AWS.

@alvations Eu gosto bastante da ideia de _data / model as package_ no spaCy, mas uma das consequências é que se você usar virtualenv , seus diretórios de ambiente podem aumentar de tamanho, já que seus pacotes estão lá. Claro, isso compra versões de dados / modelo completamente isoladas e auditáveis, o que é valioso para um projeto com atualizações frequentes de modelo como spaCy, mas não um almoço grátis 😕

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

peterbe picture peterbe  ·  5Comentários

vezeli picture vezeli  ·  3Comentários

talbaumel picture talbaumel  ·  4Comentários

alvations picture alvations  ·  4Comentários

alvations picture alvations  ·  3Comentários