Зачем нужен Python 2.7 для portage?

Потому что несовместимость между версиями?

потому что куча софта не поддерживают третий питон. у меня PYTHON_TARGETS="python3_7". как ты думаешь, сколько строк у меня в файле /etc/portage/paclage.use/python2?

сколько? стало интересно, сколько мне самому надо будет написать.

Десятки, причем даже среди скобочных 3.6 и 3.7. Но думаю сам портеж работал на 2.7 и только из-за приближающегося конца поддержки ветки 2.7 сделали совместимость с 3.6.

28. не так много, как я думал

Самому портажу python2.7 не нужен уже достаточно давно.

Зачем по-умолчанию в portage

Затем, что таким образом ты можешь выбрать версию и всего единожды пересобрать портаж (и при этом даже ничего не сломать).

Ведь для работы одного экземпляра portage на одном компьютере хватило бы и одной установленной версии питона.

Зато если портаж собран для двух питонов, если один из них ты сломаешь, он продолжит работать на втором. А сломать python-exec много ума не надо.

не так много, как я думал

У меня было что-то порядка семидесяти строк с упоминанием *python*, причём это для того, чтобы максимально избавиться от python2.7, оставив его только для софта, не умеющего в python3.

у меня таких на арче всего 11, включая сам py2, из них только 4 что-то делают, остальные просто подтянулись.

Хотя мне сложно понять, почему gimp, inkscape, playonlinux и bleachbit всё ещё тянут за собой старый питон

если портаж собран для двух питонов, если один из них ты сломаешь, он продолжит работать на втором.

Вот ни разу такое не понадобилось. Я-то думал, что есть какие-то ещё программы, которые используют portage специально в варианте питона 2.7.

Старый питон торопятся хоронить по политическим и напрочь долбанутым причинам.

А если присутствует, значит людям работать надо, нужна совместимость. Вообще если что-то хорошо не знаешь лучше руководствоваться принципом: работает - не трогай.

нужна совместимость.

Совместимость каких-то программ с portage на питоне 2.7.

Вот я спрашиваю, что это за программы такие?

Потому что portage (в целом) - это одна из последних вещей в системе, откуда уберут поддержку python2.7. До этого она там должна быть просто потому, что пока должен быть доступен вариант включения только PYTHON_TARGETS_PYTHON2.7.

Почему бы не оставить только 3.6 ?

Так оставь себе только его.

Ведь для работы одного экземпляра portage на одном компьютере хватило бы и одной установленной версии питона.

Я надеюсь, этот тезис основан на твоём исследовании кода portage, всех eclass и используемых EAPI?

он основан на wishfull thinking

должен быть доступен вариант включения только PYTHON_TARGETS_PYTHON2.7.

Ну так всё, умер 2.7, конец жизни две недели назад настал

В твоих фантазиях он умер. В апреле планируется 2.7.18. Но даже это ничего не меняет.

Пока в дереве есть пакеты требующие python2 его никуда не уберут, а таких пакетов полно, в том числе firefox и chromium в процессе сборки время от времени требуют python2.7. Соответствующие баги сам найдёшь.

Что-то я не заметил твоих коммитов по ускорению процесса портирования части приложений из дерева на использование исключительно >=python3.6

написано что с 2020-01-01 превращается в тыкву

Там такого не написано. Скрипты всё так же продолжают работать и продолжат. Даже на windows7.

На вашем локалхосте, да. В нормальных компаниях внутренними инструкциями СБ запрещено использование ПО поддержка которого производителем этого ПО завершена.

Там такого не написано.

Почему ты так думаешь? Там есть табличка, в ней колонка с заголовком «End of life», а в строке для версии 2.7 написана конкретная дата. Которая уже прошла. Это значит, что питон 2.7 всё.

инструкциями СБ

Но банки то продолжают работать и тот же windows 7 ее везде ещё вывели из использования. Да это упущение и ЦБ должна запретить такое.

Но даже если есть инструкции, то это не отменяет факта, что скрипты запускаются и делают то, что должны.

А учитывая, что финальный релиз питона 2.7 ещё только в апреле будет, то ещё есть пара месяцев и СБ может спать спокойно.

Нет,это значит только то, что они дальше не будут вносить исправления.

При этом

Planned future release dates:

2.7.18 code freeze January, 2020 2.7.18 release candidate early April, 2020 2.7.18 mid-April, 2020

Почему ты его тогда не удалишь?

я его вообще первый раз в жизни вижу, и он вызывает у меня непонимание.

Кого видишь? Где ты пропал все годы между 2.6 и 3.0. Опять же, возьми и удали.

он вызывает у меня непонимание.

Ещё не поздно расширить кругозор.

Зато если портаж собран для двух питонов, если один из них ты сломаешь, он продолжит работать на втором. А сломать python-exec много ума не надо.

Тогда не логичнее ли будет сделать его на манер youtube-dl, чтобы всё в одном жирном бинарнике?

Мы тут про юзы, а не про пакеты, если что.

Вот ни разу такое не понадобилось.

В процессе перехода на другой Python понадобится.

Тогда не логичнее ли будет сделать его на манер youtube-dl, чтобы всё в одном жирном бинарнике?

Нет, иначе придётся тащить в систему все версии Python. Плюс это сломает python-exec, на котором в Gentoo держится весь питонософт (сломав python-exec ломается питонософт).

Вот у меня был portage на python 2.7
Я инсталлирую питон 3.6, затем portage для питон 3.6
Затем переключаюсь на новый python и portage при помощи eselect
и всё, старый portage и старый питон не нужны.

В процессе перехода на другой Python понадобится.

Непонятно, каким образом он понадобится.

Тут недавно профиль обновляли на 17.1 вот примерно так же надо убрать из профиля python 2.7

Я про сборку в один независимый бинарник. Типа https://www.pyinstaller.org/

Непонятно, каким образом он понадобится.

А ты вначале удали 2.7, и потом устанавливай 3.6/3.7, сразу поймёшь.

17.1

Совсем немного не дождался. Но я вряд ли вернусь на Linux, даже ради Gentoo.

Тогда это отменяет необходимость в python-exec, на котором жёстко завязан portage. В общем, ПРИШЛО ВРЕМЯ ПЕРЕУСТАНАВЛИВАТЬ ШINDOШS КРОВЬ КИШКИ РЕИНСТАЛЛЯЦИЯ.

сорян, плохо прочитал

мне в Fedora 31 из-за одной софтины, которой нужен python 2.7 пришлось chroot с Fedora 30 собирать

Совместимость каких-то программ с portage на питоне 2.7.

Вот я спрашиваю, что это за программы такие?

Те, которые по каким-либо причинам работают со старым питоном. Лично я конкретного списка не знаю, потому что меня этот вопрос не волновал.

Ну так всё, умер 2.7, конец жизни две недели назад настал

Кто-то до сих пор программы написанные в 80ые и 90ые использует. Пока кто-то пользуется программой - она не умерла.

Вообще это нездоровая тенденция что-то выкидывать/закапывать потому что кто-то где-то написал что оно устарело. Ты путаешь цикл разработки/поддержки командой разработчиков с использованием.

Ещё ты мог бы конкретней раскрыть свою задачу - для чего именно потребовалась такая информация. На конкретном примере тебе будет проще посоветовать чем давать общие ответы. Тем более что тебя, судя по тому как ты хочешь получить однозначный вопрос, волнует конкретика.

мне в Fedora 31 из-за одной софтины, которой нужен python 2.7 пришлось chroot с Fedora 30 собирать

Вот кстати хороший пример какие излишние проблемы создают приверженцы выкинуть что-то побыстрее.

В нормальных компаниях внутренними инструкциями СБ запрещено использование ПО поддержка которого производителем этого ПО завершена.

Это в каких конкретно? В госконторе где стоит непропатченный шиндошс, но его надо раз в Н лет заменить для попилов начальником?

Или в больших корпорациях где управленцев волнуют лишь инструкции и порядок, ибо у них ответственность перед владельцами/акционерами. Чтобы можно было в случае чего свалить ответственность на производителей софта?

Сам намедни эту дрянь убить пытался. Фиг вам! Около трех десятков приложений ею пользуется…

Другой вопрос: доколе? Доколе вообще в генте это говнище (я про пхытон) будет колбасится? Когда я смогу, наконец-то, выкинуть из системы не только передастические systemd/pulseaudio, но и хипстерские пхытоны, культяпки и прочие фекалии?

[url=https://habr.com/ru/users/eddyem/comments/]Пример[/url]. Продержаться на быдлохабре больше пары месяцев просто нереально: «карму» сливают в /dev/null.

А все от того, что сайты, подобные быдлохабре, как раз и рассчитаны на безмозглое стадо вантузоидов. Подобное же стадо голосует за угнетателя и еще радуется, что их не сразу убивают, а постепенно…

То есть в gimp в fedora теперь нет поддержки плагинов на python?

Почему бы не оставить только 3.6 ?

> cat /etc/make.conf
...
DEFAULT_VERSIONS+= python=3.8 python3=3.8

Ты свой PYTHON_TARGETS покажи! Скажем, мне пришлось оставить так:

PYTHON_TARGETS="python2_7 python3_6"
PYTHON_SINGLE_TARGET="python3_6"

при этом трем пакетам пришлось еще и PYTHON_SINGLE_TARGET установить в 2_7:

app-office/scribus PYTHON_SINGLE_TARGET: python2_7
app-office/openoffice-bin PYTHON_SINGLE_TARGET: python2_7
sys-devel/clang:8/8= PYTHON_SINGLE_TARGET: python2_7

app-office/openoffice-bin PYTHON_SINGLE_TARGET: python2_7

Запихни в локальный оверлей и выкини оттуда python. Либо напиши багрепорт (добавить флаг python): питон нужен только для поддержки скриптов, но из-за одного CVE поддержка этих скриптов отрубается переименованием скрипта для выполнения скриптов при установке пакета. Так что по умолчанию всё равно не работает.

В случае clang либо ставить 9 версию, либо создать stable request для него, если он и его зависимости больше 30 дней в дереве, нет багов, связанных с ними. Но бот багзиллы это, кажется, всё равно проверит.

Со скрибусом выход только live-ebuild :(

Дык, ладно бы только эта троица! У меня еще несколько десятков мелких пакетов зависит от 2_7!

Ну вот :( тогда сложнее.

У меня в make.conf:

# Не пишу PYTHON_TARGETS, чтобы не мешать автоматическим обновлениям генты с 3.6 на 3.7 и т.д.
USE="$USE -python_targets_python2_7"

А вот в package.use/python2 – уже довольно давно пусто; последнее что там было – это зависимости inkscape-0.92.* (пока не обновил его на 1.0_beta2). Многие установленные пакеты юзают python2, но как обязательную опцию, им настройка не нужна.

Лично у меня clang9 и libreoffice. (Кстати удивился: кому нынче нужен openoffice?) На днях добавили net-wireless/crda:4 с питон3, несколько зависимостей ушло. Осталось:

• libmypaint:1 – уйдёт когда GIMP начнёт выкатывать 2.99.*, там у них есть тикет обновления на libmypaint:2.

• chromium – в апстриме есть тикет, но пока что они не чешутся.

• spidermonkey, qtwebkit, bluez, cups, automake, gnome-keyring, net-snmp, libxslt, libnatspec, yasm, scons (косвенная зависимость subversion[http]) – хз чё когда.

кому нынче нужен openoffice?

Опенофис не так сильно глючит, как либра. Либра - вообще отстой дикий.

Кстати, на фоне этих обновлений перестал работать дропбокс! Раньше я матюкался на эту гадость, что она единственная требовала жирный qtwebkit, а сейчас оно еще и работать вообще перестало!

Надо искать что-то подобное, потому что ни яндекс-диск, ни гуглодрайв у меня не работают. А то написал бы с использованием inotify обновлялку + раз в час можно было бы по крону синхронизировать.

libmypaint:1 – уйдёт когда GIMP начнёт выкатывать 2.99.*, там у них есть тикет обновления на libmypaint:2

Уже вкатывает в live-ebuild. Надо проверить, но libmypaint2 ,емнип, ещё не вышел, поэтому пока 1.4, а вот от зависимости слота 1.3 можно, пожалуй, принудительно избавиться как-нибудь, если не забуду проверить.

В багзилле gentoo на gegl багов полно :(

libmypaint2 три недели назад beta вышла, надо бы потихоньку ebuild лепить.