SZ
Size: a a a
2019 November 16
KK
а смысл от него? только чтобы не делать ручками venv и не запускать внутри buildout?
Ну мне обычно не нужны venv, хватает одного билдаута. Особенно в ситуации когда системный питон в линухах уже не 2.7 и при этом далеко не 3.8 и даже не 3.7 (в LTS релизах). А потому сложно словить конфликт с пакетами в системе.
AS
а чего такого в питоне 3.7/3.8 что позволяет ловить конфликты ?
KK
Ничего - просто когда ставишь их на lts убунту, то у них нет вообще ни каких пакетов, т.к. это не системный питон (сейчас он 3.6 в убунте 18.04)
KK
Хотя ладно, я слукаваил - там по моему в убунте (или Debian) опять накосячили, и почему-то решили что можно пакеты от 3.6 использовать в 3.7. А потому собрали 3.7 таким образом, что он видит пакеты от системного 3.6, но там далеко не всё работает. Это легко чинится через специальный файлик /etc/python3.7/sitecustomize.py. Там просто надо из sys.path удалить папку с пакетами системного питона 3.6.
KK
Этот файлик идёт вместе с 3.7 в убунте. И в дефолтным варианте сразу видно что 3.7 не дружит с системными пакетами, т.к. в этом файлике прописана активация хуков из пакета apport_python_hook
KK
При запуске 3.7 сразу в консоль вываливаются ошибки.
2019 November 17
n
А у вас не все в докере ещё, я правильно понимаю? Есть задача ставится на тачку напрямую?
KK
Ну почти всё в докере. Но только нигде ведь не пишут, что докер заменяет собой Make. Вот и тут он не заменяет билдаут, т.к. это специализированый вариант Make с блекджеком и девушками, заточеный под питон. Кроме того разработку ведём на локальном хосте, а не в контейнерах.
AM
Ну почти всё в докере. Но только нигде ведь не пишут, что докер заменяет собой Make. Вот и тут он не заменяет билдаут, т.к. это специализированый вариант Make с блекджеком и девушками, заточеный под питон. Кроме того разработку ведём на локальном хосте, а не в контейнерах.
Кроме отсутствия поддержки со стороны IDE что-то останавливает разрабатывать лакально в контейнерах?
KK
Кроме отсутствия поддержки со стороны IDE что-то останавливает разрабатывать лакально в контейнерах?
А какой в этом профит? Неудобства очевидны, а особых плюсов вроде не видно. Это же всего лишь более мощная изоляция от системы, других задач оно вроде не решает. Или предлагаешь использовать докерфайл вместо билдаута или make файла? По моему он не очень удобен для этого.
AM
А какой в этом профит? Неудобства очевидны, а особых плюсов вроде не видно. Это же всего лишь более мощная изоляция от системы, других задач оно вроде не решает. Или предлагаешь использовать докерфайл вместо билдаута или make файла? По моему он не очень удобен для этого.
Из плюсов:
1. Автоматом поднимаются зависимые сервисы и не конфликтуют порты аля 2 постгреса без лишней настройки. Удобно для микросервисов. Тесты двух микросервисов можно гонять одновременно.
2. pytest я гоняю в intranet чтобы сразу видеть где у меня изоляция страдает.
3. Если код должен плодить дочерние процессы, то во время отладки не надо ходить убивать зомбаков.
1. Автоматом поднимаются зависимые сервисы и не конфликтуют порты аля 2 постгреса без лишней настройки. Удобно для микросервисов. Тесты двух микросервисов можно гонять одновременно.
2. pytest я гоняю в intranet чтобы сразу видеть где у меня изоляция страдает.
3. Если код должен плодить дочерние процессы, то во время отладки не надо ходить убивать зомбаков.
AM
Если хочется изоляции каждой Make команды в отдельном контейнере, хорошо подойдёт инструмент vaga.
KK
Это больше про запуск чего-то в контейнерах, нежели про разработку находясь внутри контейнера. Запуск тестов в контейнере я тоже делаю иногда, когда создаю или сильно меняю базовый образ для продакшена. Всякие базы и др. сторонние сервисы тесты сами поднимают в контейнерах через сессионные фикстуры.
🦉K
где-то читал что лучше всего стул-седло
Лучше всего стул - лежак
V
Лучше всего стул - лежак
ой хоспади , зачем я задал тенденцию....)
🦉K
ой хоспади , зачем я задал тенденцию....)
Какую именно)?