DLL HELL
От: кубик  
Дата: 01.08.22 14:14
Оценка: +15 :))) :))) :))) :))) :))) :))) :)))
Блин, сколько воя было про DLL hell в винде.
Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Re: DLL HELL
От: Sharov Россия  
Дата: 01.08.22 14:25
Оценка:
Здравствуйте, кубик, Вы писали:

К>Блин, сколько воя было про DLL hell в винде.

К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...

conda, venv?
Кодом людям нужно помогать!
Re: DLL HELL
От: sergey2b ЮАР  
Дата: 01.08.22 14:27
Оценка:
Что не так с Python ?
Re[2]: DLL HELL
От: vsb Казахстан  
Дата: 01.08.22 14:58
Оценка:
Здравствуйте, sergey2b, Вы писали:

S>Что не так с Python ?


Кто-то venv не осилил, похоже. А так всё с ним нормально.
Re[3]: DLL HELL
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 01.08.22 15:16
Оценка: 8 (6) +2
Здравствуйте, vsb, Вы писали:

vsb>Кто-то venv не осилил, похоже. А так всё с ним нормально.


Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.

Как жить с Питоновскими либами в таких условиях я так и не понял. Взял одну библиотеку с одними зависимостями, взял вторую с другими зависимостями и... И оно может в какой-нибудь момент среди работы просто упасть. Или совсем не заведётся. Вот недавний пример: SwinTransformer зависит от mmdetection и ещё десятка других библиотек годичной давности. У меня он завёлся, работает.
В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу.
Отсюда идёт простой архитектурный высер: делать на каждый чих свой докер, в нём микросервис и приложение превращается из одного простого линейного пайплайна без копирования памяти внутри себя в сборище докерных микросервисов, которые при работе тормозят. Теоретически, оно получается легко масштабируемым, но только мне надо, чтобы оно работало на дохленьком ноуте у клиента.
Re[4]: DLL HELL
От: novitk США  
Дата: 01.08.22 20:32
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.


Ты делаешь странные веши или я не понимаю. Если не bleeding edge, то conda/venv. Если bleeading edge, то зачем две версии, если все равно надо руками строить?
Re: DLL HELL
От: кубик  
Дата: 02.08.22 03:55
Оценка: 1 (1) +2 :)
Всё это какая то херня типа зеленой энергии. Под видом того что опенсорс, выгода, в IT заводят такую штуку что постоянно надо апгрейдится, копаться в зависимостях которые сами зависят
а после всего окажется что какая то хренотень (pip) не может SSL с SNI.. Зачем качаете сами ?? Вызывайте wget или curl!
В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
Сейчас ... ну зеленая энергия, не иначе.
Re[5]: DLL HELL
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 02.08.22 04:48
Оценка:
Здравствуйте, novitk, Вы писали:

N>Ты делаешь странные веши или я не понимаю. Если не bleeding edge, то conda/venv. Если bleeading edge, то зачем две версии, если все равно надо руками строить?


Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями. Зависимости во многом совпадают, но из-за разных API вместе не работают. По отдельности в разных venv оно работает, каждый в своей песочнице. В одном проекте уже нет.
Re[4]: DLL HELL
От: Vzhyk2  
Дата: 02.08.22 06:14
Оценка: :)
N>В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу.
Ну во-первых, пользуйся собственно движками нейронок, а не обертками над ними. Да обертки часто удобнее, но там бардака больше, чем в собственно движках. А если влоб будешь юзать cuda и cudnn, то с обратной совместимостью там всё очень неплохо.
Второе, купи пачку тесл или заплати прилично гугла или амазону и обучишь быстро. Разрабы движков нейронок работают на суперкомпах и в общем им пофиг на мелочь в виде 3090.
Re: DLL HELL
От: jahr  
Дата: 02.08.22 06:16
Оценка: +3
Здравствуйте, кубик, Вы писали:

К>Блин, сколько воя было про DLL hell в винде.

К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...

Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.
Re[2]: DLL HELL
От: Vzhyk2  
Дата: 02.08.22 06:19
Оценка: 1 (1) +2 :)
К>В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
В линухе со либами из стандартных реп тоже всё отлично, даже лучше, чем в винде.
Описанный дурдом с питоном и он одинаков и в винде и в линухе.
И добавлю питон хорош для прототипирования и ужасен для прода.
Re[6]: DLL HELL
От: Vzhyk2  
Дата: 02.08.22 06:20
Оценка: -1 :))
N>Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями. Зависимости во многом совпадают, но из-за разных API вместе не работают. По отдельности в разных venv оно работает, каждый в своей песочнице. В одном проекте уже нет.
Ну так в питоне такие традиции. На обратную совместимость там никогда внимания не обращали. Потянул питона в прод — ССЗБ.
Re[4]: DLL HELL
От: Ватакуси Россия  
Дата: 02.08.22 11:45
Оценка: +2
vsb>>Кто-то venv не осилил, похоже. А так всё с ним нормально.

N>Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.


N>Как жить с Питоновскими либами в таких условиях я так и не понял. Взял одну библиотеку с одними зависимостями, взял вторую с другими зависимостями и... И оно может в какой-нибудь момент среди работы просто упасть. Или совсем не заведётся. Вот недавний пример: SwinTransformer зависит от mmdetection и ещё десятка других библиотек годичной давности. У меня он завёлся, работает.

N>В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу.
N>Отсюда идёт простой архитектурный высер: делать на каждый чих свой докер, в нём микросервис и приложение превращается из одного простого линейного пайплайна без копирования памяти внутри себя в сборище докерных микросервисов, которые при работе тормозят. Теоретически, оно получается легко масштабируемым, но только мне надо, чтобы оно работало на дохленьком ноуте у клиента.

Собственно, это проблема не питона как такового, а сложностей (или раздутости — как угодно можно воспронимать) этих библиотек. Ровно такая же фигня с nodejs (там ещё хуже бывает, когда по капотом — питон 2, например), линуксом и прочими пакетными системами.
Лично я вижу только один способ — постоянно обновляться и жить на самых последних (и при этом рабочих) версиях. Иногда приходится брать исходники и править, да
Все будет Украина!
Re[3]: DLL HELL
От: Ватакуси Россия  
Дата: 02.08.22 11:48
Оценка: :))
К>>В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
V>В линухе со либами из стандартных реп тоже всё отлично, даже лучше, чем в винде.
V>Описанный дурдом с питоном и он одинаков и в винде и в линухе.
V>И добавлю питон хорош для прототипирования и ужасен для прода.

Это банально неправда. Стандартные репы содержат версии 3-5 летней давности. Не нравится? Собирай сам из исходников (несколько дней, а то и недель радости тебе обеспечено).
Питончик отлично работает везде, где у людей прямые руки. Как собственно и с любым другим инструментом.
Все будет Украина!
Re[2]: DLL HELL
От: Ватакуси Россия  
Дата: 02.08.22 11:50
Оценка: 3 (1)
К>>Блин, сколько воя было про DLL hell в винде.
К>>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...

J>Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.


Напрямую. Пример. Берёшь tornado, который именно на линухе работает типа хорошо. Берёшь psycopg2, открываешь соединение к базе и вызываешь tornado.fork, в итоге (хотя документация говорит об обратном) у тебя ОДНО соединение между разными процессами. Как?
Это нужно спросить у линуха.
Все будет Украина!
Re[2]: DLL HELL
От: кубик  
Дата: 02.08.22 13:22
Оценка: :)
J>Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.

Потому что добавляется хелл от разнообразия других библиотек. И несовместиности дистров.
Re[6]: DLL HELL
От: novitk США  
Дата: 02.08.22 14:47
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями.

И ты решаешь это в плюсах при помощи правки исходников, как я понял. Почему тоже самое не сделать для питона? Геморой конечно увеличен(врапперы), но претензия к организации библиотек имхо не совсем по адресу.
Re[7]: DLL HELL
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 02.08.22 14:50
Оценка: 1 (1) +2
Здравствуйте, novitk, Вы писали:

N>И ты решаешь это в плюсах при помощи правки исходников, как я понял.


Да, все проблемы вижу на этапе компиляции.

N>Почему тоже самое не сделать для питона? Геморой конечно увеличен(врапперы), но претензия к организации библиотек имхо не совсем по адресу.


1. Потому что это динамика, я тупо не вижу всех проблем сразу.
2. Библиотек реально очень много. Как-то так получается, что плюсовых зависимостей всегда меньше и всегда они консервативнее.
Re[4]: DLL HELL
От: Константин Б. Россия  
Дата: 02.08.22 15:37
Оценка: +2 -1 :)
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, vsb, Вы писали:


vsb>>Кто-то venv не осилил, похоже. А так всё с ним нормально.


N> ...правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.


N> ...Пытаюсь поправить, не получается.


Т.е. в библиотеке А сломали обратную совместимость и ты смог код поправить. В библиотеке Б сломали совместимость сильнее и ты не смог код поправить.

И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
Re[8]: DLL HELL
От: novitk США  
Дата: 02.08.22 15:56
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>1. Потому что это динамика, я тупо не вижу всех проблем сразу.

N>2. Библиотек реально очень много. Как-то так получается, что плюсовых зависимостей всегда меньше и всегда они консервативнее.

Это обычный флейм "статика/динамика"? Извините, что влез.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.