или можно просто не использовать KOI8-R

А последние pip'ы, как известно, заточены под UTF-8 (хлипкий парсер которого выпадает в осадок от «некорректных последовательностей байтов»).

Проблемы ретроградов, кто не хочет на третьем питоне писать

А зачем использовать python3 с koi8-r?

Аааа так он и так на третьем... Значит товарищь просто упоролся по кои8

а что если юзеру кодировок хватает возможностей кои-8 кодировок, зачем ему покупать копуктеры мощнее, ради utf-8? </idioticmode>

Если за версией pip и критическими исправлениями следит ментейнер репозитория дистрибутива, то можно отключить проверку версии pip опцией --disable-pip-version-check, можно также прописать в pip.conf disable_pip_version_check = 1. Также можно выставить переменную окружения PIP_DISABLE_PIP_VERSION_CHECK=1

Даже бздуны на юникоде.

это где такая криокамера ?

Она на одного.

pip, например, таким путём

собери тогда уж пакет

Собрать стабильный релиз Python'а с локалью KOI8-R можно

но не нужно.

Я придумал лайфхак.
1. Берешь UTF8.
2. Пользуешься только латинскими буквами.
3. ???
4. Нет никакой разницы с koi8-r, все работает и ничего не нужно патчить!

ТС всё еще клоунядничает. Продолжай.

и ничего не нужно патчить

На самом деле, и при локали KOI8-R в целом ничего патчить не нужно. И тот же Python 3 продолжает поддерживать KOI8-R из коробки. Вся засада в том, что pip - это отдельный набор скриптов, который не читает локаль юзера. В нём гвоздями прибита одна конкретная кодировка. Что и приводит к его падению когда он пытается прочитать информацию о дистрибутиве. Но, это легко исправляется переписыванием прописанной кодировки. В итоге рабочие строки принимают такой вид:

> grep koi8-r distro.py
                    v = v.decode('koi8-r')
        stdout, stderr = stdout.decode('koi8-r'), stderr.decode('koi8-r')
            line = line.decode('koi8-r') if isinstance(line, bytes) else line
            line = line.decode('koi8-r')
>

Весеннее обострение?

Зачем тебе нужен питон?

Прочитал тэги как «koi8-r, RIP». Серьезно, кому-то стало хуже от перехода на UTF-8? Я уже и не помню когда я в последний раз видел крякозябры.

Для скриптов на Python'е, разумеется.

кому-то стало хуже от перехода на UTF-8?

Да.

Moe uses ISO-8859-15 instead of UTF-8 because an 8-bit character set (combined with romanization if needed) can convey meaning safely and more efficiently than UTF-8 can.

UTF-8 is a great tool for tasks like writing books of mathematics or mixing Greek with Chinese in the same document. But for many other everyday computing and communication tasks, an 8-bit code like ISO-8859-15 is much more practical, efficient and reliable. There is no such thing as an «invalid» or «out of range» ISO-8859-15 character.

UTF-8 is fine for non-parsable, non-searchable documents that must look «pretty», but not so fine for things like configuration files or C++ source code. UTF-8 greatly hinders parsability (and may even become a security risk) by providing multiple similar-looking variations of basic alphabetic, punctuation, and quoting characters. UTF-8 also makes search difficult and unreliable. For example, searching for a word like «file» in an UTF-8 document may fail if the document uses the compound character 'fi' instead of the string «fi».

ТС всё еще клоунядничает. Продолжай.

Ну, по крайней мере он сделал фикс (пусть и сомнительной необходимости), что говорит о наличии определенного скилла, которого нет у некоторых местных снобов ;)

Breaking news, лол.

Какого скилла? Создавать себе трудности? Этот декоде-энкоде все забыли как страшный сон перейдя на третью ветку питона, где юникод во все поля и все работает (ну кроме некоторых наркоманских штук вот типа тех что оп делает которые до сих пор не могут в юникод).

Алсо, он ничего не исправил. Он пожаловался что там прибит юникод, оторвал его и прибил свои кои. Уж тогда смотрел бы что там в системе стоит, глядишь кому-нибудь с cp866 пригодилось бы.

Этот декоде-энкоде все забыли

Нет. В оригинальном pip'е decode() есть, но с захардкоженным utf-8. В этом и засада:

> grep utf-8 distro.py
                    v = v.decode('utf-8')
        stdout, stderr = stdout.decode('utf-8'), stderr.decode('utf-8')
            line = line.decode('utf-8') if isinstance(line, bytes) else line
            line = line.decode('utf-8')
>

python3 + koi8r? Я еще понимаю python2, но python3? Он же весь заточен под юникод, и кириллицу и так нормально ест. Тебя Эдик покусал что-ли?

Ещё раз повторяю, что вся засада именно в pip'е. Засада возникает именно на этапе установки при локали KOI8-R. Именно из за захардкоженности в нём UTF-8. Парсер этого UTF-8 ни разу не может прожевать то, что не соответствует его представлениям об UTF-8:

Exception:
Traceback (most recent call last):
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/commands/install.py", line 272, in run
    with self._build_session(options) as session:
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/basecommand.py", line 72, in _build_session
    insecure_hosts=options.trusted_hosts,
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 329, in __init__
    self.headers["User-Agent"] = user_agent()
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 93, in user_agent
    from pip._vendor import distro
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 656, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 626, in _load_backward_compatible
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/distro.py", line 1050, in <module>
    _distro = LinuxDistribution()
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/distro.py", line 594, in __init__
    if include_lsb else {}
  File "/tmp/tmpv9mt0nrv/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/distro.py", line 922, in _get_lsb_release_info
    stdout, stderr = stdout.decode('utf-8'), stderr.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcb in position 22: invalid continuation byte
make: *** [Makefile:1099: install] Ошибка 2

коммунити или как

так это, ты багу нашел.

багу желательно бы починить как следует, чтоб оно кодировку брало из системы, а не надеялось на совпадение системной кодировки с utf-8/кое8/любой_другой_хардкод.

осилишь сам допинать до разработчиков?

О БОЖЕ МОЙ! ДА ВСЕМ НАСРАТЬ!!!

Привет, тебе до сих пор заняться нечем?

Присоединюсь к n_play. Ты, конечно, хорошее дело сделал, но лучше напиши об этом в багтрекер pip-а.

Попробую потом.

Ппц, я на UTF-8 уже в мохнатом 2004 сидел, а тут в 2018 люди осилить не могут, я в шоке.

Не всем нужен UTF-8.

UTF-8 - это стандарт. Как секунда или ампер. Koi-8 и прочие - это локальные, местные кодировки, с которыми всегда будет затык в новом софте по причине нужды 2-3 калекам.

Софт бывает разный. И даже в таком софте как, например, git нет ничего юникодно-специфичного. Он просто перекладывает строки с места на место как они есть. Независимо от того, в какой они кодировке. И если софт работает только с ASCII, то для него также нет принципиальной разницы какая локаль у юзера - UIF-8 или какая-то совместимая с ASCII однобайтная. Ну и т.д. Разница появляется тогда, когда софт должен разбирать строки. И такой софт скорее будет разбирать их по местным локальным правилам, поскольку все языки, в общем-то, местные.

Т.е ты патриот и пишешь код который принципиально не поддается i18n

i18n - это просто перевод текстовых строк на разные языки. И это может быть перевод на пучок однобайтных кодировок. Да, для перевода на все-все-все языки мира придётся переводить и на китайский, и на арабский,... и т.д., но это уже другой вопрос. Тут может быть и гибридная БД текстовых строк, из которой уже имеющиеся строки будут просто перекладываться один в один. Это не нечто юникодно-специфическое.

При этом, повторяю, вполне можно ограничиться, например, англоязычным интерфейсом и ASCII.

Представляю как это удобно

For example, searching for a word like «file» in an UTF-8 document may fail if the document uses the compound character 'fi' instead of the string «fi».

А ещё можно написать «f\0i», и тогда тоже поиск по «fi» ничего не даст. Печаль-беда.

Есть большая разница между кашей из отдельных символов и кашей из комбинированных codepoint'ов.

А вот и подтянулся Python 3.6.5 с pip 9.0.3. Свежий патч: http://saahriktu.org/downloads/patches/pip-9.0.3-koi8r-patch.sh .

А в чём принципиальная разница? Для человеского ока разницы что так, что этак никакой, а символы разные.
Дa и бaнальнoе смешeниe лaтиницы и кириллицы тoже пoд КОI8-R никтo нe отмeнял.

При чём тут «человеческое око»? Разница в том, что с точки зрения однобайтной кодировки один отдельный символ всегда один отдельный символ как его ни крути. А в юникоде никаких отдельных символоы изначально вообще нет. Есть просто набор codepoint'ов. И нужно всё это парсить. И только после предварительного разбора становится понятно где какой комбинированный символ. В однобайтных кодировках такого безобразия отродясь не было и не будет.