Parece que Github está inactivo / bloqueando el acceso al contenido sin procesar en el repositorio.

Mientras tanto, la solución temporal es algo como esto:

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

Actualmente, descargar el directorio gh-pages.zip y reemplazar el directorio nltk_data es la solución de trabajo por ahora.

Antes de encontrar otro canal para distribuir nltk_data , utilice la solución anterior.

~ Curiosamente, solo parece afectar la cuenta de usuario nltk . Funciona bien en la bifurcación: https://raw.githubusercontent.com/alvations/nltk_data/gh-pages/index.xml~

~ Hacer esto también funcionaría: ~

@alvations ¡ Muchas gracias!

¿Existe alguna alternativa para las descargas de línea de comandos como esta?
python -m nltk.downloader -d ./nltk_data punkt

@plaihonen , debería poder usar este índice alternativo haciendo algo como python -m nltk.downloader -u https://pastebin.com/raw/D3TBY4Mj punkt

@rvause Funciona perfectamente. ¡Gracias!

+1. esta fue una sorpresa de varias horas esta mañana. Pasó por completo sin pasar por la descarga de nltk por ahora

Actualmente, GitHub bloquea el acceso porque "un usuario consume una gran cantidad de ancho de banda solicitando archivos". También han sugerido que deberíamos buscar una forma diferente de distribuir paquetes de datos, por ejemplo, S3.

Incluso con un índice alternativo, ¿alguien encuentra que algunos paquetes todavía no funcionan?

Específicamente, para mí, el paquete de palabras vacías me da un 405, los demás (marrón, wordnet, punkt, etc.) no.

sí, tampoco puedo descargar las palabras vacías de nltk. Recibo el error 405 cuando lo hago> python -m nltk.downloader -u http://nltk.github.com/nltk_data/

Oye, estoy intentando ejecutar python -m nltk.downloader stopwords , pero obtengo el error 405. ¿Alguien puede señalarme en la dirección correcta?

@ dfridman1 @ prakruthi-karuna lea el número anterior. La solución es:

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

Tenemos algunos proyectos que utilizan esto en nuestro sistema ci. En lugar de tener que actualizarlos todos con el parámetro -u, ¿existe otra forma de especificar esos datos? ¿Quizás una variable de entorno o un archivo de configuración?

@alvations parece que su solución ya no funciona, ya que la versión bifurcada también está prohibida. ¿Alguien está actualmente en contacto con el soporte de github sobre esto?

>>> 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

Acabo de abrir un ticket con ellos a través de la página de contacto.

Parece que GitHub está al tanto y está trabajando en el problema. Esto es lo que me dijeron:

Lo siento por la molestia. Tuvimos que bloquear las solicitudes a las URL raw.githubusercontent.com para el repositorio nltk / nltk_data y sus bifurcaciones porque el uso excesivo estaba causando problemas con el servicio GitHub. Estamos trabajando para resolver el problema, pero lamentablemente no podemos permitir esas solicitudes en este momento.

Sí, acabo de recibir esto también:

Hola Liling,
Trabajo en el equipo de soporte en GitHub y quería notificarle que hemos tenido que bloquear temporalmente el acceso a los archivos que se entregan desde raw.githubusercontent.comURLs para el repositorio alvations / nltk_data. Actualmente, un usuario consume una gran cantidad de ancho de banda solicitando archivos de ese repositorio, y nuestra única opción en este momento es bloquear todas las solicitudes. Estamos trabajando activamente en formas de mitigar el problema y nos pondremos en contacto contigo cuando tengamos una actualización. Háganos saber si tiene alguna pregunta.
Saludos, Shawna

@zxiiro Ver https://stackoverflow.com/questions/3522372/how-to-config-nltk-data-directory-from-code

@ ewan-klein @stevenbird Creo que necesitamos una nueva forma de distribuir datos, pero eso requerirá una revisión del nltk.downloader.py .

Algunas sugerencias:

• https://zenodo.org/
• https://www.kaggle.com/datasets/new#
• https://github.com/ayemos/akagi y https://speakerdeck.com/ayemos/make-your-data-grab-and-go

Al parecer, no tenemos más remedio que cambiar el canal de distribución de datos:

Hola Liling,
Quería hacer un seguimiento de esto con información adicional. Hemos estado discutiendo el problema internamente, y es muy probable que no restauremos el acceso sin formato a los repositorios en la red de bifurcaciones nltk / nltk_data en el futuro previsible. El problema es que hay varias máquinas que llaman a nltk.download () con una frecuencia muy alta. No podemos restaurar el acceso sin procesar hasta que la actividad se detenga. Siéntase libre de compartir este mensaje con la comunidad nltk. Esperamos que quien esté haciendo esto sea alertado del problema y detenga cualquier proceso que esté haciendo esto.
Saludos, Jamie

Uno pensaría que podrían bloquear esas direcciones IP específicamente. Pero tal vez haya más que eso.

Tengo una imagen de la ventana acoplable que descarga nltk_data, pero no la estaba reconstruyendo con frecuencia. Espero no ser uno de esos usuarios de alto tráfico ...

¿Existe un proceso de instalación que no dependa de github?

Quizás alguien configuró incorrectamente sus scripts en AWS. @todos , ayúdenos a verificar sus instancias mientras encontramos una alternativa a la distribución de datos

Hola Liling,
No podemos compartir números específicos, sin embargo, las solicitudes provienen de una gran cantidad de instancias de AWS. Sospechamos que podría ser un script o un proceso de construcción que salió mal. No sabemos mucho más allá de eso.
Saludos, Jamie

Bueno, eso es un alivio, no uso AWS.

:aliviado:

En cuanto al código, tal vez tengamos que cambiar la frecuencia con la que se actualiza el mismo paquete desde nltk downloader.py también. De lo contrario, independientemente del canal de distribución al que migremos, se producirá la misma interrupción del servicio.

¿Quizás funcionaría algo basado en torrents?

No estoy seguro de cómo es la licencia, pero puede hacerla pública en s3: https://aws.amazon.com/datasets/

@alvations parece que solo la descarga de gzip funciona por ahora. Y los paquetes debían moverse a la carpeta /home/username/nltk_data/ .

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/

¿Tenemos ya una solución temporal?

@darshanlol @alvations mencionó una solución. Si está tratando de construir una ventana acoplable, lo siguiente funcionó para mí:

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/

Intento cambiar la URL predeterminada en 'nltk.downloader.py', pero el problema persiste.

La solución alternativa sugerida ya no funciona:

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

Actualmente, esta es la única solución que funciona:

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 dijo @alvations , esta es la única solución que funciona.

PATH_TO_NLTK_DATA = / inicio / nombre de usuario / nltk_data /wget https://github.com/nltk/nltk_data/archive/gh-pages.zipdescomprimir gh-pages.zipmv nltk_data-gh-pages / $ PATH_TO_NLTK_DATA

Pero incluso después de descargar todas las páginas, tenía problemas, ya que mi descargador NLTK no podía detectar todos los paquetes descargados, por lo que es posible que deba cambiar manualmente el valor del directorio de descarga a través del comando.

Esta página tiene el comando adecuado que utilicé para configurar paquetes de datos NLTK

Haga clic en el enlace anterior para obtener una respuesta.

Aquí hay un par de propuestas para resolver este problema después de leer y encontrar alternativas.

Hacer corpora pipable

• Primero, lo cambiaremos de modo que todos los nltk_data sean pip. (Por lo tanto, cada nuevo entorno requerirá una nueva instalación de pip y ya no dependemos del directorio físico)
• También necesitaremos hacer un seguimiento de algún tipo de índice para que la descarga obtenga y rastree las versiones.

• Entonces también necesitamos tener algún tipo de revisión en el código, el downloader.py y toda la interfaz del lector de corpus relacionada

• Posiblemente las limitaciones de pip (desde el lado de PyPI) pueden detener a los usuarios / máquinas deshonestos con solicitudes de alta frecuencia

Alojar los datos en S3 / Zenodo o algún host privado

Esto requeriría que simplemente volvamos a vincular los enlaces en index.xml a los enlaces apropiados. Después de configurar los archivos individuales en el servidor web.

Pero si el tráfico sigue siendo alto debido a que algún script de instalación / automatización salió mal, terminamos molestando a un proveedor de servicios a otro.

¿Cualquier otra sugerencia?
¿Algún alma valiente que quiera asumir esto?

@ harigovind511 , sí, debe colocar la carpeta nltk_data descargada en una de las ubicaciones estándar donde el nltk sabe buscarla, o agregarla a nltk.data.path para indicarle dónde buscar. El descargador automático solo busca una ubicación estándar.

Probablemente sea necesario limitar / resolver la velocidad de las máquinas deshonestas para que esto no vuelva a mostrar su fea cabeza. Mi voto sería por pip a menos que haya algún problema (o tabú) con los paquetes grandes en pip.

El uso de pip también resolvería el nltk.download () manual y la gestión de paquetes en código.

¿Los archivos parecen copia de seguridad? Sin embargo, parece prudente seguir buscando mecanismos de distribución alternativos. En mi propia organización, aunque planeamos pasar al hosting interno y registrarnos trimestralmente

Me gustaría entender qué hace $ PATH_TO_NLTK_DATA. ¿Está configurando una URL de descarga local alternativa para donde NLTK obtiene sus datos?

Me gustaría configurar un caché local de datos NLTK, así que me preguntaba si configurar esto le dice a NLTK que funcione sin conexión.

Dado que la raíz del problema es el abuso del ancho de banda, parece una mala idea recomendar la recuperación manual de todo el árbol nltk_data como solución. ¿Qué tal si nos muestra cómo los identificadores de recursos se asignan a las URL, @alvations , para que pueda wget solo el paquete punkt , por ejemplo?

La solución a largo plazo, creo, es hacer que sea menos trivial para los usuarios principiantes obtener el paquete de datos completo (638 MB comprimidos, cuando verifiqué). En lugar de organizar (y pagar) más ancho de banda para desperdiciar en descargas inútiles, deje de proporcionar "all" como opción de descarga; en cambio, la documentación debería mostrarle al scripter distraído cómo descargar los recursos específicos que necesitan. Y mientras tanto, deje el hábito de escribir nltk.download("all") (o equivalente) como muestra o uso recomendado, en stackoverflow (lo estoy mirando, @alvations) y en las cadenas de documentación del descargador. (Para explorar el nltk, nltk.dowload("book") , no "all" , es igual de útil y mucho más pequeño).

En la actualidad, es difícil determinar qué recurso se debe descargar; si instalo el nltk y pruebo nltk.pos_tag(["hello", "friend"]) , no hay forma de asignar el mensaje de error a una ID de recurso que pueda pasar a nltk.download(<resource id>) . Descargar todo es la solución obvia en tales casos. Si se puede parchear nltk.data.load() o nltk.data.find() para buscar la identificación del recurso en tales casos, creo que verá que su uso en nltk_data disminuirá significativamente a largo plazo.

@zxiiro $PATH_TO_NLTK_DATA no tiene ningún significado para el nltk, es solo una variable en el script de muestra. La variable de entorno $NLTK_DATA tiene un significado especial. Consulte http://www.nltk.org/data.html , se explican todas las opciones.

@alexisdimi estuvo de acuerdo con el nltk.download('all') . Lo siento, fue una respuesta tan antigua de mis primeros días. Debería desaconsejarlo. Cambié la respuesta SO a nltk.download('popular') lugar: https://stackoverflow.com/questions/22211525/how-do-i-download-nltk-data

Uno de los problemas con wget directamente a un paquete es que todavía depende del contenido sin procesar en github. Durante el tiempo de inactividad, el enlace https://github.com/nltk/nltk_data/blob/gh-pages/packages/tokenizers/punkt.zip también conducía al error 403/405.

Por lo tanto, el trabajo fue descargar todo el árbol de git. En retrospectiva, podría no ser una buena idea.

Parece que se ha levantado el bloqueo, ¡eso es genial! Ahora espero que haya algunos tickets que sirvan para prevenir problemas similares en el futuro (tal vez en la línea que sugerí, tal vez no).

(Por cierto, ¿debería marcarse _este problema como "Cerrado", ahora que las descargas funcionan de nuevo?)

@alexisdimi poner advertencias que sugieran a los usuarios descargar los modelos adecuados es una buena idea.

Para aquellos que ejecutan NLTK en un entorno de CI. Me gustaría proponer GH-1795, que permite especificar una URL alternativa para la descarga. La idea aquí es que uno puede configurar una copia local de nltk_data en un servidor web (o incluso python -m http.server) y luego tener una variable global que pueda anular la URL de descarga.

Esto es para que podamos anular sin modificar las llamadas de comandos locales de los proyectos para incluir -u de un sistema CI como Jenkins.

Pregunta a Github con respecto a la distribución de datos pip usando lanzamientos e instalación de pip:

¡Gracias Jamie por el apoyo!

Estamos buscando alternativas para alojar nltk_data y una de ellas es alojarlas como versiones de repositorio, como lo hace SpaCy https://github.com/explosion/spacy-models/releases

¿Podríamos comprobar con usted si se ejecutará el mismo bloque si se realizan solicitudes de alta frecuencia similares a las versiones del repositorio? ¿O las versiones del repositorio se tratan de manera diferente al contenido sin procesar en Github?

Saludos,
Liling

Algunas actualizaciones en el lado de Github:

Hola Liling,

El uso de Releases solo mueve las solicitudes a una parte diferente de nuestra infraestructura. Si ese volumen de ancho de banda se reiniciara, aún tendríamos que bloquear esas solicitudes, incluso si fueran versiones.

Hemos intentado pensar en algunas formas en que los paquetes de datos podrían permanecer en GitHub, pero, honestamente, no hay una buena solución. Simplemente no estamos configurados para ser un CDN de alto volumen.

Salud,
Jamie

@owaaa / @zxiiro +1 sobre alojamiento interno para CI. Estamos haciendo esto ahora, y la ventaja para los usuarios de EC2 / S3 es que puede poner los datos (o el subconjunto que necesita) cerca de donde desea construir las máquinas. Si se encuentra en zonas de disponibilidad, puede replicar los depósitos donde lo necesite y ser más robusto con lo que sucede fuera de AWS.

@alvations Me gusta bastante la idea _data / model as package_ en spaCy, pero una de las consecuencias es que si usa virtualenv , los directorios de su entorno pueden aumentar de tamaño a medida que sus paquetes viven allí. Por supuesto, esto le permite comprar versiones de datos / modelos completamente aisladas y auditables, lo cual es valioso para un proyecto con actualizaciones frecuentes de modelos como spaCy, pero no un almuerzo gratis 😕