LINUX.ORG.RU
решено ФорумAdmin

[ALT линукс] [сизиф] поломан питон2

 , ,


0

1

доброго, коллеги. по работе прихлось заняться тесным изучением «Альт» линукса и вот столкнулся с некоторыми проблемами

обновил с 10.2 Сервер до Сизифа через epm, и вроде всё норм, но что-то не так с питоном. попытка запустить кое-какой софт приводит вот к чему:

  File "/var/www/itwebinstall/utils/app-configure.sh", line 17, in <module>  
    import copy  
ImportError: No module named copy

ну это ладно, софт специфичесеский, может поэтому. но, даже попытка просто посмотреть список установленных модулей вот что выдаёт:

Traceback (most recent call last):  
  File "<string>", line 1, in <module>  
  File "/usr/lib64/python2.7/site.py", line 449, in __call__  
    import pydoc  
ImportError: No module named pydoc  

что за чертовщина?.. попытки нагуглить решение приводят только к печали

UPD: нужен именно python2.7 и он установлен. проблема точно известна и она заключается в том, что в Сизифе поломана эта версия, потому что большая часть базовых питоновских модулей была вырезана
как бы вы действовали в этом случае, если бы вам понадобилось запустить софт? у меня есть идея попробовать развернуть питоновский набор 2.7 standalone вариантом со всеми необходимыми модулями, или же переделать под python3

UPD2: подсказали с решением, нужно доустановить модули самому

У них там python-modules отдельным пакетом идёт, тебе надо его доустановить. sudo apt-get install python-modules

Перемещено hobbit из general

★★★

Последнее исправление: Dimez (всего исправлений: 6)
Ответ на: комментарий от adn

когда его проектировали, совершенно не подумали как потом копировать и распростанять написанное

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

Что-то я не вижу этот «отраслевой стандарт» в своем дистрибутиве (ubuntu). Почему?

Потому что вы не имеете к отрасли никакого отношения, это видно по вашему непониманию обсуждаемой темы. И причем тут убунта если мы говорим о питоне и его экосистеме?

Вот да, ставить anaconda в систему ради одной программы - это как раз оно.

Я человек старой закалки, в мое время девопсов не было, были системные администраторы которые реализовывали решения решающие не только конкретную текущую проблему, но и все проблемы подобного класса в будущем. Это то что некоторые называют администраторской «ленью».

Так вот, установка anaconda как раз решение из этой серии, закрывающее запуск все подобных программ требующих вторую версию питона или вообще любой версии питона отличающейся от системной.

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

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

их, по-факту, всего две. А вот с библиотеками всё сложнее.

И причем тут убунта если мы говорим о питоне и его экосистеме?

Мы говорим про anaconda (и менеджер пакетов conda), которую почему-то не включили в состав самого распространенного дистрибутива linux. Еще раз вопрос: почему «отраслевой стандарт» (кстати в какой отрасли?) обходят стороной создатели дистрибутивов?

в мое время девопсов не было, были системные администраторы которые реализовывали решения решающие не только конкретную текущую проблему, но и все проблемы подобного класса в будущем

а потом их всех выгнали на мороз из-за того что неэффективны. но при чем тут они? или в голове сидит, что docker исключительно инструмент devops?

adn ★★★★
()

как бы вы действовали в этом случае, если бы вам понадобилось запустить софт?

  1. выкинул бы альт
  2. выдал бы полный отчёт работодателю о том, что альт неюзабельный кусок этого самого и форсировал бы через работодателя обращение в тп альта с полной фиксацией всех недочетов альта для того, чтобы у менеджмента закрепилась чёткая устойчивая связь: альт=проблемы, а лоббисты перехода на альт получили бы по шапке
  3. пока обращение в альт торчит на стадии клуш из тп, дающих нерелевантные советы, сделал бы ./configure && make %% make install тарболлу со с вторым питоном и, представив продолжение работы руководству, отметил бы, что хвалёная техподдержка лоббируемого дистрибутива не стоит денег, которые за неё уплачены
anonymous
()
Ответ на: комментарий от Obezyan

засирать

–prefix

Как будто те кто опакечивают питон в свои дистрибутивы имеют отношение к его разработчикам.

Пользоваться питоном от мейнтейнеров дистрибутива, прошедших проверку личности - это доверие дистрибутиву. Доверие может быть неоправданным в случае всяких мутных дистрибутивов, но процедура есть всё равно. Пользовать бинарями, скачанными непонятно откуда непонятно от кого непонятно с какими гарантиями - это называется жрать с пола. 10 лет назад именно за такое и ржали с вантузятников, плачущих от винлокера.

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

их, по-факту, всего две.

Их десятки только третьей версии.

А вот с библиотеками всё сложнее.

Именно так, зачастую программа требует какого-нибудь torchvision под конкретную cu116 определенной версии питона, буквально на 3.10 работает, а на 3.11 - нет. А некоторые вещи вообще работают только в 3.6-3.7 под конкретные версии CUDA биндингов. Это не проблема питона, это недоработка NVIDIA которая не заботится о переносимости того что выкладывает в бесплатный доступ, и так сожрут. И они правы, нормальных альтернатив нет.

Мы говорим про anaconda (и менеджер пакетов conda), которую почему-то не включили в состав самого распространенного дистрибутива linux.

Потому что это дистрибутив общего назначения. В нем также нет R из коробки, потому что среднестатистическому красноглазику он не нужен.

Еще раз вопрос: почему «отраслевой стандарт» (кстати в какой отрасли?) обходят стороной создатели дистрибутивов?

Отрасль - HPC (высокопроизводительные вычисления), сюда входит все от разработки нейросетей до стат вычислений и обработки данных (python+R).

Нет никакого смысла делать отдельный дистрибутив для этого. Связку CUDA + anaconda + (python + R) разных версий и библиотек можно поставить хоть на убунту хоть на арч.

а потом их всех выгнали на мороз из-за того что неэффективны. но при чем тут они?

Их порешал бизнес, для бизнеса лучше десяток студентов-головастиков девопсов которые заменяемы по щелчку пальца чем один админ на котором держится все и bus factor = 1

или в голове сидит, что docker исключительно инструмент devops?

В голове сидит что если докер использует не для развертывания приложения на десятки/сотни/тысячи машин, а для запуска микросервисов в продакшене, то на проекте нет нормального архитектора. Скорее всего его вообще нет, а инфру настроил программист быстренько почитав на хабре что вообще можно изобразить.

Докер это наверное самый часто неправильно используемый инструмент в наше время.

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

Я понимаю что вы открыли первую страницу прочитали Anaconda.org allows anyone to distribute their conda and standard Python packages to the world. и сделали вывод про есть с пола.

Это показывает насколько вы далеко от данной темы. Анаконда буквально предоставляет те же репозитарии пакетов. Основные это main, anaconda и conda-forge. Первые два делает сама анаконда, conda-forge это community репозитарий спонсируемый NumFOCUS уже лет 6, а самой репе лет 10.

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 2)
Ответ на: комментарий от Obezyan

Потому что это дистрибутив общего назначения.

Ты странный. Сам же пишешь, что никто не использует anaconda за пределами узкозаточенных под нейронки датасатанистов, но почему-то порекомендовал это поделие автору топика, как единственный правильный подход. (И, кстати, R в Ubuntu вполне себе есть)

Их порешал бизнес, для бизнеса лучше десяток студентов-головастиков девопсов которые заменяемы по щелчку пальца чем один админ на котором держится все

Наоборот же. Я хорошо помню то время когда на два сервера приходилось по одному администратору. И они постоянно сидели в консоли (часто через telnet). Сейчас же один человек спокойно может обслуживать сотни машин и все его действия будут зафиксированы в git’е. Кстати достаточно мало тех системных администраторов смогли освоить devops практики.

В голове сидит что если докер использует не для развертывания приложения на десятки/сотни/тысячи машин, а для запуска микросервисов в продакшене, то на проекте нет нормального архитектора.

Бред какой. Ты вообще представляешь что такое docker контейнер и что он из себя представляет? Потому что именно Docker является «отраслевым стандартом». Он как минимум позволяет использовать один и тот же готовый образ, что на локальном окружении, что на тестовом, что и в продакшне. И ты всегда знаешь что твои тесты были проведены на том же коде/бинарнике и с теми же библиотеками, что будут крутиться в продакшне.

Докер это наверное самый часто неправильно используемый инструмент в наше время.

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

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

Я хорошо помню то время когда на два сервера приходилось по одному администратору. И они постоянно сидели в консоли

Про админов постоянно сидящих в консолях орнул чаечкой. Это какие-то студенты эникеи.

Потому что именно Docker является «отраслевым стандартом».

У микросервисных яваскриптизеров. Вообще, докер получил популярность в первую очередь у неосиляторов линукса, сидящих на винде, я помню те времена когда они с горящими глазами ставили докер потому что не нужно больше мучаться с денвером для локальной копии проекта… Это где-то в 2015м началось, уже 10 лет пролетело.

Ты вообще представляешь что такое docker контейнер и что он из себя представляет?

Я пользовался ими еще до того как вы узнали слово Docker. Тогда это был LXC. Боюсь это вы не понимаете что такое докер, откуда растут у него ноги и почему дополнительная абстракция приносит проблемы в сопровождении и безопасности.

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

Вы сейчас взяли и разом перечеркнули все свои рассуждения. Именно conda в мире питона подходит для подобных задач, не docker/lxc. Я бы еще понял если бы вы спорили о conda vs venv что хотя бы охарактеризовало вас как питон миддла, но походу нет, мы зря теряем время.

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

Да вы оба нихрена не понимаете, он и сейчас lxc в обертке ;)

Именно так, докер это буквально расширение LXC. Я пытался объяснить выше что тыкать в меня незнанием докера, когда я буквально застал его рождение и взросление немного странно.

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

Про админов постоянно сидящих в консолях орнул чаечкой. Это какие-то студенты эникеи.

Не, вполне себе взрослые дядьки, администрирующие solaris на sun fire.

Это где-то в 2015м началось, уже 10 лет пролетело.

А ты уверен, что docker в windows работал в 2015ом? Я не в теме тут.

Тогда это был LXC. Боюсь это вы не понимаете что такое докер

Я то как раз понимаю и никогда не стал бы его сравнивать с lxc.

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

И почему же? Я с удовольствием послушаю, как и многие на этом сайте.

Именно conda в мире питона подходит для подобных задач, не docker/lxc

Еще раз. lxc никакого отношения к docker’у не имеет (ну кроме того, что использует те же механизмы ядра), как и к задаче запуска определенного кода с определенным интерпретатором и набором библиотек. Видимо просто conda понятна, а docker осилить не получилось.

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

Да можешь как угодно меня характеризовать. Я вообще не программист, а lead devops/sre с опытом администрирования linux с конца 90х.

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

Именно так, докер это буквально расширение LXC

Ух как всё запущено. Расширение lxc, которое служит для того, чтобы использовать его близко с функциональностью docker называется lxd.

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

А ты уверен, что docker в windows работал в 2015ом? Я не в теме тут.

Точно работал зимой 2015/2016.

И почему же? Я с удовольствием послушаю, как и многие на этом сайте.

Теперь мне уже не хочется (c) пингвин на стульчике

Еще раз. lxc никакого отношения к docker’у

Docker имеет отношение к lxc, он буквально на нем основан. Потому что, фактически, lxc это интерфейс, реализованный в виде набора низкоуровневых команд. А докер это приложуха на гошечке которая их дергает. Да, он еще дергает всякие cgroups из ядра линукса, но мы сейчас не об этом.

Да можешь как угодно меня характеризовать. Я вообще не программист, а lead devops/sre с опытом администрирования linux с конца 90х.

А, это все объясняет, я серьезно. Я общался с вами как со средней руки программистом имеющим 4-6 летний опыт. Прошу прощения. Теперь понятно такое отношение к докеру, я не осуждаю, это буквально ваш хлеб так сказать.

Ух как всё запущено. Расширение lxc, которое служит для того, чтобы использовать его близко с функциональностью docker называется lxd.

lxd такое же «расширение» lxc как и докер. Можете мне не верить, погуглите что у lxd под капотом. Вообще, все что я пишу банально можно перепроверить - загуглив, просто для расширения кругозора.

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

Теперь мне уже не хочется (c) пингвин на стульчике

А разговоров то было (с) Маша после секса

Docker имеет отношение к lxc, он буквально на нем основан.

Нет. Docker вообще никаким боком к lxc. Ну, блин, почитай документацию. (Да, ранние версии, еще до массового использования действительно использовали lxc, но это быстро закончилось).

Ты не понимаешь суть Docker’а и почему он стал так популярен, считая его только продвинутым chroot’ом. Почитай документацию.

Можете мне не верить, погуглите что у lxd под капотом.

У lxd под капотом естественно lxc (и я об этом сам написал). Причем тут Docker?

Вообще, все что я пишу банально можно перепроверить - загуглив

Эх, вот если бы ты сам не ленился это делать.

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

Предлагаю закончить обсуждение. Я никогда не преследовал цель образовывать девопсов в каких либо вопросах.

Углубляться в «runc использует libcontainer драйвер, который фактически является Gо имплементацией С интерфейса LXC по дерганию cgroups в ядре чтобы отвязаться от его реализации на С и иметь все на Go» с девопсами это Сизифов труд.

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

Я никогда не преследовал цель образовывать девопсов в каких либо вопросах.

Черт, мне бы такую манию величия.

«runc использует libcontainer драйвер, который фактически является Gо имплементацией С интерфейса LXC по дерганию cgroups в ядре чтобы отвязаться от его реализации на С и иметь все на Go»

  1. Интересно откуда ты взял такую странную цитату

  2. libcontainer перестал существовать в районе 2014го года. Откуда ты его выкопал - загадка.

  3. Docker это далеко не только продвинутый chroot c использованием cgroups. Почитай про него. Я серьезно. Очень много интересного узнаешь.

adn ★★★★
()
Ответ на: комментарий от adn
  1. Интересно откуда ты взял такую странную цитату

Это моя цитата.

  1. libcontainer перестал существовать в районе 2014го года. Откуда ты его выкопал - загадка.

Последний коммит в его репозитарии был 3 дня назад. Обратите внимание что он часть runc.

  1. Docker это далеко не только продвинутый chroot c использованием cgroups. Почитай про него. Я серьезно. Очень много интересного узнаешь.

Докер это не только ценный мех, но и GRPC handlers для runc который containerd который lxc который control groups + namespaces в ядре.

Я бы потыкал носом в офф репу, но я что-то ее не наблюдаю. Есть только комьюнити репа moby, которая лишь частично содержит код докера (как они утверждают), но даже там не вычистили все до конца.

Вообще, мне уже надоело биться головой о стену непонимания, откройте консоль, наберите:

docker info | grep -i runtime

если не меняли рантайм то увидите что по-умолчанию он runc, посмотрите выше по тексту это слово, зайдете в его репозитарий и увидите внутри libcontainer, после чего попадете в рекурсию т.к. по вашим словам «libcontainer перестал существовать в районе 2014го года.».

загоняю девопсов в рекурсию, дорого, стойкий эффект, гарантия.

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

Это моя цитата.

Черт, хочу такую же манию величия, чтобы самому себя цитировать, выдавая за чью-то мудрость.

Докер это не только ценный мех, но и GRPC handlers для runc который containerd который lxc который control groups + namespaces в ядре.

Рука-лицо. То что ты напиcал равносильно: «pandas это jupyter notebook, который ipython, который json. Поэтому pandas - это тот же json. И я все про него знаю.». Не позорься и прочитай документацию на Docker (и,видимо на lxc).

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

Черт, хочу такую же манию величия

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

По поводу вашего высказывания «libcontainer перестал существовать в районе 2014го года» и проверки что же там в рантайме у докера вы ожидаемо слились, тк возразить там буквально нечего, понимаю.

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

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

Может щелкнет в голове что-нибудь, хотя надежды все меньше если честно.

А что должно щелкнуть?

Что Docker - это lxc? Это не так.

Что anaconda - это единственный вариант для запуска кода на разных версиях python? Это тоже не так.

«libcontainer перестал существовать в районе 2014го года» и проверки что же там в рантайме у докера вы ожидаемо слились, тк возразить там буквально нечего, понимаю.

Да сложно на самом деле с бредом спорить. Docker модульный и состоит из нескольких частей. Раньше всем управлял libcontainer (он до сих пор в архиве докера находится). Тот libcontainer, который ты мне прислал, возможно и имеет с ним общую историю, но сейчас эта библиотека является только одной из библиотек для runC - одного из движков для запуска контейнера.

я с возрастом становлюсь нетерпим к воинствующему невежеству.

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

adn ★★★★
()