Комментарии 27
Контейнеры наше всё. Специально начал изучать контейнеры именно из-за описанного вами случая: среда ОС+ПО перестают нормально работать при необходимости использовать разные версии ПО или когда неудачно установил ПО. Очень рекомендую посмотреть в сторону контейнеров.
В дополнение к беспроблемной установке вы получаете еще безопасность (как-то не сильно хочется запускать чужой скрипт на родной машинке) и портируемость (чтобы развернуть программную инфраструктуру на другом компьютере достаточно просто взять текстовый файл с настройками контейнера и применить его)
Контейнеры хороши, но для каких-то небольших задач такой уровень изоляции не нужен. Можно обойтись и pyenv, который одной командой ставит нужные версии Python (и не удаляет их при обновлении).
Минусы меня не смущают, но стало очень интересно, с каким утверждением люди не согласны.
Если что, минусы не мои, но я попробую обосновать свои вышеизложенные аргументы. Преимущество контейнеров в их универсальности. Например, я новичок в Python и понятия не имел про pyenv. Мне проще создать контейнер (дело нескольких секунд) и в нем развернуть новую версию.
Кроме того, проблемы совместимости могут не ограничиваться возможностями pyenv. Например, это могут быть какие-то разные версии внешней библиотеки, которые использует ваш скрипт.
Резюмируя: контейнеры позволят одним махом отсекать целые слои потенциальных проблем и не париться и не тратить время на исследования.
Так я ж не говорю, что контейнеры — это плохо. Мой комментарий как раз и начинается с обратного утверждения. Я на работе постоянно пользуюсь контейнерами (в Kubernetes сложно без этого), и локально частенько веду разработку в контейнере примонтировав данные в отдельный том, так как иногда нужно специфическое окружение. Я просто хотел сказать, что это не единственный способ.
Насчёт того, что вы не знали про pyenv, так это не проблема. Теперь-то знаете. :)
А то, что есть ситуации, когда pyenv неудобен (такие, конечно, есть), совершенно не означает, что он неудобен всегда.
Да, контейнер можно запустить за пару секунд, но pyenv устанавливает интерпретаторы в систему, и тут вообще не нужно ничего устанавливать и запускать, интерпретатор уже есть.
Это как спор, что лучше: контейнеры или виртуальные окружения. Оба хороши в своих областях и друг другу не мешают. Это ложная дихотомия.
Насчёт того, что вы не знали про pyenv, так это не проблема. Теперь-то знаете. :)
Однако, я по прежнему не знаю как им пользоваться. Поэтому, в случае любой сомнительной ситуации просто разверну новый контейнер.
Иными словами, контейнеры помогают, когда что-то не работает и при этом непонятно почему. Довольно частая ситуация, кстати, поскольку когда понятна причина, проблема быстро фиксится и о ней вообще не рассуждают.
В принципе, поскольку вы уже знакомы с контейнерами, я могу считать свою миссию выполненной :) Почему-то мне подумалось, что кто-то может не знать про такую удобную и мощную технологию.
Но для каких-то небольших задач и изоляция не нужна.
Надо танцевать с бубном -- возьмём контейнер, где всё просто.
Надо что-то мелкое для себя -- можем и поправить если что не так.
А "надо иметь зоопарк версий с гвоздями прибитыми версиями" это всё же пережиток прошлого, когда были либо VM что долго и тяжело либо контейнеры которые совсем не легковесные.
Но для каких-то небольших задач и изоляция не нужна.
Именно это я и написал. :)
Ну вот, скажем, веду я разработку на маке (да-да, я знаю, что статья про Ubuntu), который выдал мне работодатель. Контейнеры там работают внутри виртуальной машины, стартуют не так уж быстро, работают неповоротливо, а примонтированные тома очень медленные. Это у линукс-бояр контейнер — это изолированный процесс. Так что накладные расходы всё же есть.
Например, у меня есть проект с бинарным модулем на Python, который в системе собирается за минуты, а в контейнере приходится танцевать с бубном и всё равно сборка на порядок медленнее.
Так что контейнеры — это не всегда решение для локальной разработки. Хотя иногда, как я уже написал, ими пользуюсь. Тем более, что в VS Code это делать суперлегко и удобно.
Насчёт прибитых гвоздями версий. Вполне реальна ситуация, когда одном проекте Python 3.8, в другом Python 3.10, а в системе вообще Python 3.9. C pyenv установить интерпретаторы можно в одну строку (хотя это можно сделать и системным пакетным менеджером, я ниже упоминал PPA для Ubuntu). И тут прибитые гвоздями интерпретаторы — это благо, так как виртуальные окружения, в которых я веду разработку, не сломаются от того, что какой-то интерпретатор внезапно удалился по какой-то причине.
Новичкам только докера не хватает, ага ))
Устанавливаете нужный питон из исходников (инструкций в инете выше крыши), устанавливаете venv и source ... activate. Среда для hello world готова. Если и это окажется слишком сложно, то я утверждаю, что для соискателя сойдёт любая версия трёшки :))
Сталкивался с аналогичной проблемой обновления Python в Ubuntu 20.04. Неправильное обновление может сломать систему, нужно быть осторожным вводя команды в консоли.
Ну хоть бы для статьи в листингах версии поправили, а то в каждом листинге разные версии фигурируют, что может запутать новичков.
Достаточно просто установить pyenv, который одной командой решит все проблемы.
Как вариант, в убунту можно подключить репозиторий deadsnakes со всеми версиями Python.
Устанавливать что-то руками с sudo в обход пакетного менеджера как в статье — это, наверное, худший способ.
К слову, altinstall — это не встроенный в Ubuntu способ, а название правила для make, которое сгенерировал скрипт от авторов Python.
Боже мой, какая дичь!
Неужели автор не слышал про virtual environment?
Придумал себе проблему и мужественно её решает. А если не Ubuntu? А если не 20 версии? А если не Linux?
Virtual environment позволяет решить вопрос python окружения везде, где бежит python одной командой без скачивания и компиляции исходных кодов. Документация - наше всё.
Дичь пишете вы. Бывает что надо (или просто захотелось) обновить питон в системе. Многие пользователи уже сталкивались с проблемами в случае неправильного обновления питона в Linux. Автор просто указывает что такая проблема есть и показывает как её можно обойти.
Поясните причину, по которой "надо просто обновить python в системе"?
Для чего? Потешить эго? А если уж "просто захотелось", то тогда не нужно рыдать. Но это явно не производственная необходимость.
Системный python необходим для конкретных системных задач, зачастую привязанных к его версии. Зачем его ломать? Поясните пожалуйста.
Автор правильно указывает на проблему, но способ, которым он её решает, сомнительный.
venv это про пакеты, а не про версии питона.
FYI, существуют пакетные инфраструктуры предоставляющие несколько версий питона, в том числе одновременно. Например, порты FreeBSD. С ними мне ни разу в жизни не приходилось запускать pip или venv.
Компиляция исходников занимает часы. Почему бы не воспользоваться услугами мертвой змеи?sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install python3.9.1
Управление несколькими версиями Python под управлением Ubuntu 20.04