Внутри виртуальной машины, еще и питоновский virtualenv разводить?
Интересный подход. А сама виртуальная машина не в докере, часом, запущена?
А то был у нас в конторе один любитель qemu-system под докером запускать.
Системный питон много для чего предназначен. Например embed-ится в постгрес именно он.
Ну то есть да, если у тебя не дистрибутив а какой-то редхатоид, там приходится вместо системного platform-python использовать что-то другое. А platform-python оставить для нужд дистрибутива, то есть для dnf, И модули десятками самому собирать. Но поскольку я это делаю не для себя, а для клиентов, то "самому собирать" - это собирать в дистрибутивные пакеты.
Раньше это иногда приходилось и для астры делать. Но теперь мы отказались от поддержки Astra 1.6, а в 1.7 уже все не настолько старье, чтобы наши питонисты не могли с этими версиями модулей работать.
А что касается кода, написанного нами для наших собственных нужд, то там скорее приходится каждый раз при dist-upgrade на новую мажорную версию дебиана с матом править код наших скриптов для совместимости с новой версией питона. То есть питон в дистрибутиве обновляется быстрее, чем у нас возникает необходимость осваивать новые фичи или даже чем мы избавимся от deprecated фич.
Самостоятельно поддерживать всю питоновскую инфраструктуру стоит если питон у тебя основной и единственный инструмент. А если он один из десятка испоьзуемых языков, то лучше спихивать возможно большую часть работы на мейнтейнеров дистрибутивов.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
no subject
Date: 2024-07-10 06:20 pm (UTC)Внутри виртуальной машины, еще и питоновский virtualenv разводить? Интересный подход. А сама виртуальная машина не в докере, часом, запущена? А то был у нас в конторе один любитель qemu-system под докером запускать.
Системный питон много для чего предназначен. Например embed-ится в постгрес именно он.
Ну то есть да, если у тебя не дистрибутив а какой-то редхатоид, там приходится вместо системного platform-python использовать что-то другое. А platform-python оставить для нужд дистрибутива, то есть для dnf, И модули десятками самому собирать. Но поскольку я это делаю не для себя, а для клиентов, то "самому собирать" - это собирать в дистрибутивные пакеты.
Раньше это иногда приходилось и для астры делать. Но теперь мы отказались от поддержки Astra 1.6, а в 1.7 уже все не настолько старье, чтобы наши питонисты не могли с этими версиями модулей работать.
А что касается кода, написанного нами для наших собственных нужд, то там скорее приходится каждый раз при dist-upgrade на новую мажорную версию дебиана с матом править код наших скриптов для совместимости с новой версией питона. То есть питон в дистрибутиве обновляется быстрее, чем у нас возникает необходимость осваивать новые фичи или даже чем мы избавимся от deprecated фич.
Самостоятельно поддерживать всю питоновскую инфраструктуру стоит если питон у тебя основной и единственный инструмент. А если он один из десятка испоьзуемых языков, то лучше спихивать возможно большую часть работы на мейнтейнеров дистрибутивов.