LINUX.ORG.RU

Поиск с помощью pip search в репозитории PyPi отключён в связи с возросшей нагрузкой

 , , ,


2

0

14 декабря произошло отключение поиска в PyPi с помощью pip search в связи с возросшей нагрузкой на сервера.

Теперь в консоли любезно сообщается:
PyPI's XMLRPC API has been temporarily disabled due to unmanageable load and will be deprecated in the near future.

График нагрузки
В прошлом году

>>> Подробности

Вообще-то уже давно «фича» не работает.

Jetty ★★★★★ ()

Ох, уж эти питонисты...

Gonzo ★★★★★ ()

а зачем он без pip search нужен? я правильно понимаю, они 300 rps не осилили разрулить?

PS: это какой-то публичный каминаут в своей профнесостоятельности

ergo ()

А что, просто скачать локальную базу для search не канает?

ncrmnt ★★★★★ ()
Ответ на: комментарий от ya-betmen

Вы так говорите, как будто на джаве это более лучше

GP ()
Ответ на: комментарий от GP

Переходим все на..

На Go/Oberon/Rust. Даже современный C++ вполне годен. Виртуальные машины, JIT и динамическая типизация не нужны.

X512 ★★ ()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Причем тут питон ? Обычный хмлрпц сервис к бд. Толи они какую то левую бд юзают, толи индексы в бд не осилили не понятно …

mx__ ★★★★★ ()
Ответ на: комментарий от t184256

Диванные аналитики и поехавшие фанаты непрерывного опакечивания каждой минорной версии каждой необходимой (доступной) библиотеки для данного языка не нужны.

mazdai ★★ ()
Ответ на: комментарий от mazdai

непрерывного опакечивания каждой минорной версии каждой необходимой (доступной) библиотеки для данного языка не нужны.

А в чем минусы? Ты против эксплуатации бедных несчастных ботов?

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

А в чем минусы?

Никто не будет создавать и поддерживать пакеты для каждого дистрибутива. Проще один раз создать пакет для родного пакетного менеджера языка и он будет везде работать. Кроме фанатиков никому пакеты программ на Python для своего дистрибутива не нужны.

X512 ★★ ()

and will be deprecated in the near future.

Аахахахаххахаха. Это всё равно что у ребёнка соску отнять, они там совсем не алё? Пусть ещё и не качает и не устанавливает пакеты, а то там тоже нагрузки на сеть и железо.

anonymous ()
Ответ на: комментарий от X512

Никто не будет создавать и поддерживать пакеты для каждого дистрибутива.

Нормальный дистрибутив и будет, автоматизированно. Смотри, например, NixOS и Hackage.

t184256 ★★★★★ ()
Ответ на: комментарий от mrdeath

Они что дураки для этого пг юзать ? Для этого есть мю (мария) в режиме без транзакций … блин забыл уже как этот режим называется.

mx__ ★★★★★ ()
Ответ на: комментарий от ergo

PS: это какой-то публичный каминаут в своей профнесостоятельности

Как будто это новость.

Когда столкнулся с инфраструктурой питона, понял, что они там в pip ломают всё что можно в рамках минорных версий, и запустить потом сколько нибудь сложное приложение на пистоне каждый раз - это лотерея. Тут и каминаута не нужно никакого

zendrz ()

Это настолько глобально, что обязательно нужно в новости?
Хоть бы кратко оповестили «а нафига оно надо».

Atlant ★★★★★ ()
Ответ на: комментарий от baist

А просто собирать пакеты с исходников уже не судьба?!

Как собирать? Руками? Тогда в репозитории не будет многих пакетов и/или они будут старых версий. Это бессмысленный механический неблагодарный труд.

X512 ★★ ()
Ответ на: комментарий от baist

«Кроссплатформенный Python такой кроссплатформенный».

Не вижу проблем с кроссплатформенностью. virtualenv работает на разных платформах.

X512 ★★ ()
Ответ на: комментарий от anonymous

а где в оригинальной новости этот текст про has been temporarily disabled due to unmanageable load and will be deprecated in the near future.?

anonymous ()
Ответ на: комментарий от eternal_sorrow

Убогий язычковый недо-ПМа кусок, не могущий мне даже нативную зависимость из репов притянуть.

Узнай лучше как надо было вместо этого бреда, ознакомившись с Nix.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от Siborgium

Затем, что ПМ должен быть один на всю систему, мощный и универсальный. Питоно-, да и вся другая язычковщина годна лишь для почеса NIH и для виндузятников, ПМом сроду обделенных.

t184256 ★★★★★ ()
Ответ на: комментарий от X512

virtualenv pip

создавать и поддерживать пакеты для каждого дистрибутива не будет многих пакетов и/или они будут старых версий

а потом ты выдаешь…

Не вижу проблем с кроссплатформенностью

Нет просто столько телодвижений для продвинутого крутого языка. Т.е. чтобы просто заработал какой-то огрызок на питоне нужно столько всего оказывается.

Получается что собирать LFS из исходников на C оттарабанивая однотипные команды вида

./configure
make
make install

куда понятнее и проще, чем имея «продвинутую» пакетную систему. Какая ирония!

baist ★★ ()
Ответ на: комментарий от anonymous

Его там нет, тем не менее нам это сообщает сам pip:

~/mydibyje$ pip search lor
ERROR: Exception:
Traceback (most recent call last):
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/pip/_internal/cli/base_command.py", line 224, in _main
    status = self.run(options, args)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/pip/_internal/commands/search.py", line 62, in run
    pypi_hits = self.search(query, options)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/pip/_internal/commands/search.py", line 82, in search
    hits = pypi.search({'name': query, 'summary': query}, 'or')
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1109, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1450, in __request
    response = self.__transport.request(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/pip/_internal/network/xmlrpc.py", line 46, in request
    return self.parse_response(response.raw)
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1341, in parse_response
    return u.close()
  File "/usr/lib/python3.8/xmlrpc/client.py", line 655, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -32500: "RuntimeError: PyPI's XMLRPC API has been temporarily disabled due to unmanageable load and will be deprecated in the near future. See https://status.python.org/ for more information.">

mydibyje ()
Ответ на: комментарий от baist

а потом ты выдаешь…

Между двумя этими утверждениями нет никакой связи. Просто использовать pip и не будет никаких проблем на любой платформе.

./configure
make
make install

Уже неактуально. Многие переходят с Autotools на Cmake и Meson.

X512 ★★ ()
Ответ на: комментарий от t184256

Затем, что ПМ должен быть один на всю систему, мощный и универсальный. Питоно-, да и вся другая язычковщина годна лишь для почеса NIH и для виндузятников, ПМом сроду обделенных.

Как система будет работать с виртуальным окружением питона?

skiminok1986 ★★★★★ ()

Читаю я тред и создаётся впечатление, что хейтеры не пробовали питон от слова «совсем». Столько глупости сконцентрировано буквально в нескольких сообщениях %)

skiminok1986 ★★★★★ ()
Ответ на: комментарий от X512

Между двумя этими утверждениями нет никакой связи.

Есть связь. Кроссплатформенный интерпетируемый язык с баттарейками не может сам себя установить, а требуется городить инфраструктуру и устанавливать дополнительное ПО.

Чтобы мне поставить драйвер для Radeon под Arch хватало скачать небольшой файлик install.sh и запустить. И о чудо, оно само все разрулило, собрало, скомпилировало, и оно работало и 3D игрушки шли под любым рандомным ядром.

С/С++ себя установить не может потому что их нужно сначала скомпилить а потом запустить.

Понимаешь я писал скрипт(один файлик ага!) для заказчика который независимо от дистра полностью поднимал всю VoIP систему с поддержкой WebRTC, КАЧАЛ(!) сишный софт, кодеки, VoIP, сервер, база данных, СОБИРАЛ его(!), УСТАНАВЛИВАЛ его(!), ЗАВОДИЛ ЗАПИСИ в базе данных MySQL, ЗАПУСКАЛ, КОНФИГИ прописывал. И оно работало с нужными версиями. И мне хватало паршивого /bin/bash интерпретатора чтобы поднимать целые системы для бизнеса.

А навороченные питонисты не могут на свой круйтешем языке просто взять и все собрать в единое целое и заставить это работать одним скриптом??? Так получается?

Имею реальный комерческий опыт в 2012 году, когда установщик sh для проги С++/Qt работал на MacOS и Debian одинаково. Я тогда здорово удивился.

Ты хочешь сказать что в 2020 году питонисты настолько упоролись, что у них огромные сложности Вселенского масштаба, когда какой-то Вася может приложится на баше на 100 строк.

baist ★★ ()
Ответ на: комментарий от skiminok1986

А зачем крутому языку питон понадобилось специальное виртуальное окружение, если он дофига такой кроссплатформенный?!

baist ★★ ()
Ответ на: комментарий от baist

может потому что это дает возможность разрабатывать несколько проектов с различными версиями пакетов?

anonymous ()
Ответ на: комментарий от baist

Кроссплатформенный интерпетируемый язык с баттарейками не может сам себя установить, а требуется городить инфраструктуру и устанавливать дополнительное ПО.

Python сейчас есть из коробки почти во всех Unix-like дистрибутивах.

хватало скачать небольшой файлик install.sh и запустить

Под Windows не работает, а Python работает включая Pip и virtualenv.

А навороченные питонисты не могут на свой круйтешем языке просто взять и все собрать в единое целое и заставить это работать одним скриптом???

Ещё как могут. Есть setup.py, можно собрать исполняемый файл со встроенным рантаймом в том числе и для Windows.

X512 ★★ ()
Ответ на: комментарий от X512

Python сейчас есть из коробки почти во всех Unix-like дистрибутивах.

создавать и поддерживать пакеты для каждого дистрибутива

Если питон есть на каждой операционке, почему я должен городить отдельную языковую пакетную систему для поддержки этих самых операционок??

можно собрать исполняемый файл со встроенным рантаймом

таскать для каждой проги файл python.exe на борту со встроенным program.py это называется «отдельным скриптом»???

baist ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.