Здравствуйте, кубик, Вы писали:
К>Блин, сколько воя было про DLL hell в винде. К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Здравствуйте, vsb, Вы писали:
vsb>Кто-то venv не осилил, похоже. А так всё с ним нормально.
Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.
Как жить с Питоновскими либами в таких условиях я так и не понял. Взял одну библиотеку с одними зависимостями, взял вторую с другими зависимостями и... И оно может в какой-нибудь момент среди работы просто упасть. Или совсем не заведётся. Вот недавний пример: SwinTransformer зависит от mmdetection и ещё десятка других библиотек годичной давности. У меня он завёлся, работает.
В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу.
Отсюда идёт простой архитектурный высер: делать на каждый чих свой докер, в нём микросервис и приложение превращается из одного простого линейного пайплайна без копирования памяти внутри себя в сборище докерных микросервисов, которые при работе тормозят. Теоретически, оно получается легко масштабируемым, но только мне надо, чтобы оно работало на дохленьком ноуте у клиента.
Здравствуйте, Nuzhny, Вы писали:
N>Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.
Ты делаешь странные веши или я не понимаю. Если не bleeding edge, то conda/venv. Если bleeading edge, то зачем две версии, если все равно надо руками строить?
Всё это какая то херня типа зеленой энергии. Под видом того что опенсорс, выгода, в IT заводят такую штуку что постоянно надо апгрейдится, копаться в зависимостях которые сами зависят
а после всего окажется что какая то хренотень (pip) не может SSL с SNI.. Зачем качаете сами ?? Вызывайте wget или curl!
В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
Сейчас ... ну зеленая энергия, не иначе.
Здравствуйте, novitk, Вы писали:
N>Ты делаешь странные веши или я не понимаю. Если не bleeding edge, то conda/venv. Если bleeading edge, то зачем две версии, если все равно надо руками строить?
Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями. Зависимости во многом совпадают, но из-за разных API вместе не работают. По отдельности в разных venv оно работает, каждый в своей песочнице. В одном проекте уже нет.
N>В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу.
Ну во-первых, пользуйся собственно движками нейронок, а не обертками над ними. Да обертки часто удобнее, но там бардака больше, чем в собственно движках. А если влоб будешь юзать cuda и cudnn, то с обратной совместимостью там всё очень неплохо.
Второе, купи пачку тесл или заплати прилично гугла или амазону и обучишь быстро. Разрабы движков нейронок работают на суперкомпах и в общем им пофиг на мелочь в виде 3090.
Здравствуйте, кубик, Вы писали:
К>Блин, сколько воя было про DLL hell в винде. К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.
К>В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
В линухе со либами из стандартных реп тоже всё отлично, даже лучше, чем в винде.
Описанный дурдом с питоном и он одинаков и в винде и в линухе.
И добавлю питон хорош для прототипирования и ужасен для прода.
N>Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями. Зависимости во многом совпадают, но из-за разных API вместе не работают. По отдельности в разных venv оно работает, каждый в своей песочнице. В одном проекте уже нет.
Ну так в питоне такие традиции. На обратную совместимость там никогда внимания не обращали. Потянул питона в прод — ССЗБ.
vsb>>Кто-то venv не осилил, похоже. А так всё с ним нормально.
N>Всё равно гемор. Если работаешь с теми же библиотеками на С++, то собираешь все на одном тулчейне, одним компилятором один раз и всё. Вышел новый TensorRT, который не совместим с предыдущим? Я не делаю второй продукт, я меняю все места, которые несовместимы так, чтобы они собирались корректно с обоими версиями, пересобираю и пользуюсь. Вышел новый OpenCV? Я не делаю новую версию своей библиотеки, а правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.
N>Как жить с Питоновскими либами в таких условиях я так и не понял. Взял одну библиотеку с одними зависимостями, взял вторую с другими зависимостями и... И оно может в какой-нибудь момент среди работы просто упасть. Или совсем не заведётся. Вот недавний пример: SwinTransformer зависит от mmdetection и ещё десятка других библиотек годичной давности. У меня он завёлся, работает. N>В проект с новой версией mmdetection (и ещё десятка других библиотек) я его уже подключить не могу, потому что там переделали API — падает во время работы. Пытаюсь поправить, не получается. В интернетах пишут, что SwinTransformer уже есть в новой mmdetection, а этот старый и его не надо использовать. Но блин! У меня на старом обучена нейросеть, которая в новом уже не загружается. По факту, мне надо несколько недель переобучать сетку, чтобы просто проверить гипотезу. N>Отсюда идёт простой архитектурный высер: делать на каждый чих свой докер, в нём микросервис и приложение превращается из одного простого линейного пайплайна без копирования памяти внутри себя в сборище докерных микросервисов, которые при работе тормозят. Теоретически, оно получается легко масштабируемым, но только мне надо, чтобы оно работало на дохленьком ноуте у клиента.
Собственно, это проблема не питона как такового, а сложностей (или раздутости — как угодно можно воспронимать) этих библиотек. Ровно такая же фигня с nodejs (там ещё хуже бывает, когда по капотом — питон 2, например), линуксом и прочими пакетными системами.
Лично я вижу только один способ — постоянно обновляться и жить на самых последних (и при этом рабочих) версиях. Иногда приходится брать исходники и править, да
К>>В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов. V>В линухе со либами из стандартных реп тоже всё отлично, даже лучше, чем в винде. V>Описанный дурдом с питоном и он одинаков и в винде и в линухе. V>И добавлю питон хорош для прототипирования и ужасен для прода.
Это банально неправда. Стандартные репы содержат версии 3-5 летней давности. Не нравится? Собирай сам из исходников (несколько дней, а то и недель радости тебе обеспечено).
Питончик отлично работает везде, где у людей прямые руки. Как собственно и с любым другим инструментом.
К>>Блин, сколько воя было про DLL hell в винде. К>>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
J>Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.
Напрямую. Пример. Берёшь tornado, который именно на линухе работает типа хорошо. Берёшь psycopg2, открываешь соединение к базе и вызываешь tornado.fork, в итоге (хотя документация говорит об обратном) у тебя ОДНО соединение между разными процессами. Как?
Это нужно спросить у линуха.
Здравствуйте, Nuzhny, Вы писали:
N>Ничего не понял. Я хотел использовать библиотеку с зависимостями годичной давности в проекте с современными зависимостями.
И ты решаешь это в плюсах при помощи правки исходников, как я понял. Почему тоже самое не сделать для питона? Геморой конечно увеличен(врапперы), но претензия к организации библиотек имхо не совсем по адресу.
Здравствуйте, novitk, Вы писали:
N>И ты решаешь это в плюсах при помощи правки исходников, как я понял.
Да, все проблемы вижу на этапе компиляции.
N>Почему тоже самое не сделать для питона? Геморой конечно увеличен(врапперы), но претензия к организации библиотек имхо не совсем по адресу.
1. Потому что это динамика, я тупо не вижу всех проблем сразу.
2. Библиотек реально очень много. Как-то так получается, что плюсовых зависимостей всегда меньше и всегда они консервативнее.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, vsb, Вы писали:
vsb>>Кто-то venv не осилил, похоже. А так всё с ним нормально.
N> ...правлю исходники (чужие исходники в том числе), чтобы они поддерживали обе версии.
N> ...Пытаюсь поправить, не получается.
Т.е. в библиотеке А сломали обратную совместимость и ты смог код поправить. В библиотеке Б сломали совместимость сильнее и ты не смог код поправить.
И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
Здравствуйте, Nuzhny, Вы писали:
N>1. Потому что это динамика, я тупо не вижу всех проблем сразу. N>2. Библиотек реально очень много. Как-то так получается, что плюсовых зависимостей всегда меньше и всегда они консервативнее.
Это обычный флейм "статика/динамика"? Извините, что влез.
Здравствуйте, Константин Б., Вы писали:
КБ>И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
Да, так и есть. Ведь pip — это часть стандартной языковой инфраструктуры. И сам язык способствует тому, чтобы на нём писали программы определённым образом.
Здравствуйте, novitk, Вы писали:
N>Это обычный флейм "статика/динамика"? Извините, что влез.
Не только это. Там ещё pip способствует тому, чтобы не было стремления соблюдать совместимость. Легко написать, легко указать версию, легко обновить. В тех же плюсах проблемы с версиями библиотек возникают, например, при использовании vcpkg (может, уже и исправили). Но динамика точно не облегчает работу.
Здравствуйте, Константин Б., Вы писали:
КБ>И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
Ещё вспомнилось, как бережно отнёсся к пользователям Торвальдс, когда отстоял незадокументированное поведение memcpy в glibc. Прикинь, он хотел, чтобы у всех работала функция, хоть по документации и не должна была. Для удобства пользователей, если ты понимаешь, о чём я.
А ещё я взял исходники С библиотеки, подключил в свой С++17 проект и оно просто заработало без единой проблемы.
Ты скажешь, что это совпадение и ерунда. А мне кажется, что С-программисты реально заботятся об обратной совместимости программ и библиотек.
Здравствуйте, Nuzhny, Вы писали:
N>А ещё я взял исходники С библиотеки, подключил в свой С++17 проект и оно просто заработало без единой проблемы. N>Ты скажешь, что это совпадение и ерунда. А мне кажется, что С-программисты реально заботятся об обратной совместимости программ и библиотек.
Ты слишком обобщаешь и преувеличеваешь, сравнивая стабильность API дедушки POSIXа с новейшими высерами ML сообщества. Все сильно зависит от конкретной библиотеки. Например по моему опыту numpy — стабилен, а pandas — нет.
Здравствуйте, кубик, Вы писали:
К>Блин, сколько воя было про DLL hell в винде. К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Здравствуйте, novitk, Вы писали:
N>Ты слишком обобщаешь и преувеличеваешь, сравнивая стабильность API дедушки POSIXа с новейшими высерами ML сообщества. Все сильно зависит от конкретной библиотеки. Например по моему опыту numpy — стабилен, а pandas — нет.
Вот так совершенно случайно оказалось, что солидный кусок numpy написан на С, а pandas целиком на Питоне. Совпадение?
Здравствуйте, Nuzhny, Вы писали: N> ... А мне кажется, что С-программисты реально заботятся об обратной совместимости программ и библиотек.
C язык "зрелый", и не используется для "однодневных" разработок в отличие от ... Поэтому имеется некая культура, что написанное однажды, должно работать настолько долго, на сколько это возможно, да и люди развивающие язык с учетом этого осторожно и бережно вносили изменения.
немного размышлений про C++
В свою очередь, с C++ получилось несколько хуже, ибо слишком много хайпа вокруг него периодически создавалось, то всем развестистое ООП (с нулевыми издержками) подавай, то на каждом углу метапрограммирование на шаблонах ...
Это безобразие послужило приманкой для теоретиков и прочих идиотов, которые от безделья и практической безграмотности, и так непростой мультипарадигменный язык, бездумно украсили "фишечками" и "рюшечками" сделав его изрядно переусложненным для среднестатистического обывателя.
А на всяких скрипто-языках типа Питона, совсем другая культура разработки, по сути пригодны подобные средства только для прототипирования (однодневок) и возможно обучения в школьных кружках.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Константин Б., Вы писали:
КБ>>И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
N>Да, так и есть. Ведь pip — это часть стандартной языковой инфраструктуры. И сам язык способствует тому, чтобы на нём писали программы определённым образом.
А определенным образом — это каким? И как именно pip этому способствует?
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Константин Б., Вы писали:
КБ>>И... ты решил что тут виноват язык на котором написана библиотека Б? 🤔
N>Ещё вспомнилось, как бережно отнёсся к пользователям Торвальдс, когда отстоял незадокументированное поведение memcpy в glibc. Прикинь, он хотел, чтобы у всех работала функция, хоть по документации и не должна была. Для удобства пользователей, если ты понимаешь, о чём я.
А еще вспомнился другой известный программист на Си — Ульрих Дреппер. Прикинь, он наоборот хотел чтобы у всех все сломалось 🤷🏿
N>А ещё я взял исходники С библиотеки, подключил в свой С++17 проект и оно просто заработало без единой проблемы.
N>Ты скажешь, что это совпадение и ерунда.
Ну вот когда библиотеки на питоне работают без проблем — это совпадение и ерунда? Или по твоему такого не бывает? )
N>А мне кажется, что С-программисты реально заботятся об обратной совместимости программ и библиотек.
Здравствуйте, Константин Б., Вы писали:
КБ>А определенным образом — это каким? И как именно pip этому способствует?
Разжую ещё раз.
Он позволяет легко получать библиотеки указанных версий. Я же написал выше. Благодаря этой лёгкости у разработчиков создаётся впечатление, что не обязательно соблюдать какую-то совместимость, ведь можно просто указать правильную версию. И это работает на мини проектах, которых на Питоне пишется много. Но когда начинаешь собирать из разных исходников что-то больше, чем проект на тысячу строк (или вообще из jupiter ноутббуков), но проблема с версионностью встаёт в полный рост и сразу видно, что о ней никто не думал. Сверху добавляем динамику и получаем тот самый python hell.
Тут ещё добавляет радости переход по версиям самого языка, я вообще не в курсе, как в Питоне эти штуки решаются и из моего поверхностного опыта кажется, что никак.
Здравствуйте, Константин Б., Вы писали:
КБ>А еще вспомнился другой известный программист на Си — Ульрих Дреппер. Прикинь, он наоборот хотел чтобы у всех все сломалось 🤷🏿
Где, как, что сломалось? Хоть ссылку на обсуждение кинь.
КБ>Ну вот когда библиотеки на питоне работают без проблем — это совпадение и ерунда? Или по твоему такого не бывает? )
Тут другая логика работает. Библиотека не работает — это аварийная ситуация. У нас может на тысячу библиотек не работать одна библиотека или 5. Это всё очень маленький процент, но во втором случае мы получаем проблем в пять раз больше. Добавь к этому, что исправляются при этом они тяжелее и получишь реальную картину.
N>>А мне кажется, что С-программисты реально заботятся об обратной совместимости программ и библиотек. КБ>Ульрих Дреппер — не C-программист?
Давай проверим! Зашёл к нему на гитхаб, там у него своих репозиториев 33, из них только 7 на С. Остальные на С++, Питоне, баше, Mathematica... Да, он не С программист, а вполне универсальный программсит, знающий и использующий много разных языков.
Но я в принципе не знал, кто он, пришлось искать. Почему ты привёл его как пример, почему сам не узнал, на чём он программирует? У тебя в принципе аргументы настоящие будут? Ты по факту задал несколько вопросов, упомянул не в тему какую-то неизвестную мне фамилию.
Здравствуйте, Ватакуси, Вы писали:
В>Питончик отлично работает везде, где у людей прямые руки.
Когда встречается фраза про "прямые руки", это всегда означает (всегда, без исключений), что на проде огребешь по полной. Потому что в реальности фраза "прямые руки" означает "хитровыделанный, переменный в самых неожиданных местах, радиус кривизны рук и мозгов". Только так, и никак иначе.
В>>Питончик отлично работает везде, где у людей прямые руки. DO>Когда встречается фраза про "прямые руки", это всегда означает (всегда, без исключений), что на проде огребешь по полной. Потому что в реальности фраза "прямые руки" означает "хитровыделанный, переменный в самых неожиданных местах, радиус кривизны рук и мозгов". Только так, и никак иначе.
Нет, не означает. Более того, с непрямыми руками ты отгребёшь с любым языком/системой/платформой и т.п.
В>>Питончик отлично работает везде, где у людей прямые руки. DO>Когда встречается фраза про "прямые руки", это всегда означает (всегда, без исключений), что на проде огребешь по полной. Потому что в реальности фраза "прямые руки" означает "хитровыделанный, переменный в самых неожиданных местах, радиус кривизны рук и мозгов". Только так, и никак иначе.
Здравствуйте, Nuzhny, Вы писали:
КБ>>А определенным образом — это каким? И как именно pip этому способствует?
N>Разжую ещё раз.
не подавись
N>Благодаря этой лёгкости у разработчиков создаётся впечатление, что не обязательно соблюдать какую-то совместимость, ведь можно просто указать правильную версию.
ээм, во многих случаях вообще не пишут версию в requirements (и не фризят тоже)
здесь и сейчас работает и норм, что там завтра будет пофиг
Здравствуйте, кубик, Вы писали:
К>В Windows как прекрасно заботились о compartibility
Дык МС и в своих питонячих либах за этим следит, и Амазон с Гуглом.
Совместимость вещь дорогая, простому Ваську нафиг не упало париться с этим для какого-то кубика.
Здравствуйте, Константин Б., Вы писали:
КБ>А еще вспомнился другой известный программист на Си — Ульрих Дреппер. Прикинь, он наоборот хотел чтобы у всех все сломалось 🤷🏿
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
КБ>>А еще вспомнился другой известный программист на Си — Ульрих Дреппер. Прикинь, он наоборот хотел чтобы у всех все сломалось 🤷🏿
M>Кто это?
Был в свое время ментейнером glibc. По стандарту memcpy не поддерживает пересекающиеся области памяти (в этом случае надо использовать memmove)
Однажды в реализацию memcpy внесли оптимизацию которая сломала код всем кто использовал memcpy неправильно.
Был жуткий скандал и срач на эту тему. Дреппер топил за то чтобы эти криворукие программисты правили свой код. Торвальдс топил за то что стандартами надо подтереться.
Здравствуйте, Константин Б., Вы писали:
КБ>Был в свое время ментейнером glibc. По стандарту memcpy не поддерживает пересекающиеся области памяти (в этом случае надо использовать memmove) КБ>Однажды в реализацию memcpy внесли оптимизацию которая сломала код всем кто использовал memcpy неправильно. КБ>Был жуткий скандал и срач на эту тему. Дреппер топил за то чтобы эти криворукие программисты правили свой код. Торвальдс топил за то что стандартами надо подтереться.
Чем не устроил очевидный промежуточный вариант — с выставленной переменной GLIBC_SLOW_MEMCPY использовать старый вариант, без неё — новый? Это невозможно реализовать без оверхеда? А там дистрибутивы для сломанных программ пускай пишут врапперы. Вроде все довольны. Ну чуток лишнего кода в glibc будет, но там такая махина, что пофиг.
К>>>Блин, сколько воя было про DLL hell в винде. К>>>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
J>>Каким боком здесь линукс? Это все питон, на винде с ним еще больше геморроя.
В>Напрямую. Пример. Берёшь tornado, который именно на линухе работает типа хорошо. Берёшь psycopg2, открываешь соединение к базе и вызываешь tornado.fork, в итоге (хотя документация говорит об обратном) у тебя ОДНО соединение между разными процессами. Как?
https://www.psycopg.org/docs/usage.html#thread-and-process-safety: > libpq connections shouldn’t be used by a forked processes, so when using a module such as multiprocessing or a forking web deploy method such as FastCGI make sure to create the connections after the fork.
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT: > Warning > On Unix, forking a process with open libpq connections can lead to unpredictable results because the parent and child processes share the same sockets and operating system resources. For this reason, such usage is not recommended
---
В> у тебя ОДНО соединение между разными процессами В> хотя документация говорит об обратном
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vsb, Вы писали:
vsb>>Кто-то venv не осилил, похоже. А так всё с ним нормально.
Pzz>Ну вообще, это фиаско, если петону нужен venv для нормальной работы.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, кубик, Вы писали:
К>>Блин, сколько воя было про DLL hell в винде. К>>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
S>conda, venv?
Есть еще Poetry, имхо, удобней работать с venv и зависимостями по сравнению с conda и pip.
Здравствуйте, vsb, Вы писали:
vsb>Чем не устроил очевидный промежуточный вариант — с выставленной переменной GLIBC_SLOW_MEMCPY использовать старый вариант, без неё — новый? Это невозможно реализовать без оверхеда? А там дистрибутивы для сломанных программ пускай пишут врапперы. Вроде все довольны. Ну чуток лишнего кода в glibc будет, но там такая махина, что пофиг.
Ну только по умолчанию надо было сделать чтобы работал старый код
Здравствуйте, σ, Вы писали:
σ>https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT: >> Warning >> On Unix, forking a process with open libpq connections can lead to unpredictable results because the parent and child processes share the same sockets and operating system resources. For this reason, such usage is not recommendedА вот и ответ на "Каким боком здесь линукс?"
Здравствуйте, кубик, Вы писали:
К>Блин, сколько воя было про DLL hell в винде.
Как будто на юниксе есть какое-то отличие.
К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Разве Питом можно использовать для чего-то серьёзного? Это же интерпретатор...
Здравствуйте, sergey2b, Вы писали:
S>Что не так с Python ?
Ктото намусорил, а убирать за собой не хочет, хочет чтобы само.
В соседних ветках же советуют ходить мусорить в другие комнаты, которые предлагают достраивать по необходимости. Ну да, так кажется что всё чище.
В>Это банально неправда. Стандартные репы содержат версии 3-5 летней давности. Не нравится? Собирай сам из исходников (несколько дней, а то и недель радости тебе обеспечено).
Вы свой проект поставляете тоже из master ветки или всё-таки сначала тестируете со всеми компонентами дистрибутива перед выпуском?
Если тесты проходят — то вы предпринимаете что либо для того, чтобы нужные версии пакетов пришли к заказчику? Ну, например, хотя бы сопровождаете собственный репозиторрий с пакетами, которые считаете стабильными?
Здравствуйте, Nuzhny, Вы писали:
N>Взял одну библиотеку с одними зависимостями, взял вторую с другими зависимостями и... И оно может в какой-нибудь момент среди работы просто упасть.
Так это у вас процесс выбора нужной библиотеки или какая-то библиотека меняет зависимости, как перчатки?
А что до "просто упасть", так любой питоновский скрипт, не зависящий ни от чего кроме стандартного рантайма, может упасть, если непротестирован.
Здравствуйте, кубик, Вы писали: К>В Windows как прекрасно заботились о compartibility, придумали разные опции, добавили всякие модули AppCompat что б все старое работло. Бережно относились к труду програамистов.
А это, пардон, как помогло проблемам Питона на винде?
Или посыл такой, что "этот Питон пришел из дьявольского Юникс мира в наш виндовый монастырь, a надо было все скрипты на VB писать"?
Здравствуйте, кубик, Вы писали:
К>Блин, сколько воя было про DLL hell в винде. К>Боже мой,какой это был детский сад по сравнению с питоном на линуксе ...
Я намедни был ошарашен тем, что pip не умеет правильно резолвить зависимости.
То есть ставим, к примеру, sphinx. Версии, к примеру, 4.5, т.к. весь процесс у техдоков заточен именно под него, и "работает — не трогай".
У него прописаны зависимости от ряда contrib-пакетов. В стиле ">=0.9.7".
pip берёт и тащит самые свежие версии этих пакетов.
И ему почему-то всё равно на то, что сами эти пакеты требуют sphinx ">= 5.0".
В итоге после выполнения pip install sphinx==4.5 ставится нерабочая комбинация пакетов.
Я-то наивно полагал, что пакетный менеджер решает систему неравенств, а не просто "рекурсивно тащим все депенды, да ещё и теряя версии".
В итоге приходится методом тыка подбирать совместимые версии и ставить их вручную
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>То есть ставим, к примеру, sphinx. Версии, к примеру, 4.5, т.к. весь процесс у техдоков заточен именно под него, и "работает — не трогай". S>У него прописаны зависимости от ряда contrib-пакетов. В стиле ">=0.9.7". S>pip берёт и тащит самые свежие версии этих пакетов. S>И ему почему-то всё равно на то, что сами эти пакеты требуют sphinx ">= 5.0".
Офигеть. За циклические зависимости принятно канделябром в приличном обществе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: S>>И ему почему-то всё равно на то, что сами эти пакеты требуют sphinx ">= 5.0". ·>Офигеть. За циклические зависимости принятно канделябром в приличном обществе.
Ну, мопед-то не мой. И циклические зависимости, в некотором смысле, это ок. Я погуглил — в питоновом комьюнити считается, что рантайм-депенды могут быть произвольно устроены; вот инсталл-депенды должны быть ациклическими.
И я, наверное, даже могу себе представить причины, которые побудили авторов сфинкса реализовать именно такую топологию.
Но как по мне, так питону нужно или крестик надеть, или трусы снять — если разрешены циклические депенды, то они должны резолвиться корректно, а не ругаться в рантайме на несовместимость пакетов.
А если запрещены — то надо консистентно ругаться на такие пакеты и отказываться их ставить вовсе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я-то наивно полагал, что пакетный менеджер решает систему неравенств, а не просто "рекурсивно тащим все депенды, да ещё и теряя версии".
Тебе встречался пакетный менеджер который работает по такому принципу?
S>В итоге приходится методом тыка подбирать совместимые версии и ставить их вручную
Ну вот я бы в такой ситуации сделал вывод что разработчики sphinx которые некорректно указали версии.
На самом деле в первую очередь конечно виноваты вы. Раз уж вас есть работающий набор версий пакетов почему вы не использовали его?
Ну допустим виноват pip. Как это по твоему должно работать? pip должен скачать все версии всех пакетов и как-то выбрать из них совместимое подмножество?
Здравствуйте, Константин Б., Вы писали: КБ>Тебе встречался пакетный менеджер который работает по такому принципу?
Формально — даже pip должен делать именно это. А иначе зачем все эти >= и <=?
КБ>Ну вот я бы в такой ситуации сделал вывод что разработчики sphinx которые некорректно указали версии.
Ну, тут возникает такой вопрос — а как корректно указать версии в такой ситуации?
КБ>На самом деле в первую очередь конечно виноваты вы. Раз уж вас есть работающий набор версий пакетов почему вы не использовали его?
КБ>pip freeze > requirements.txt КБ>pip install -r requirements.txt
КБ>Не знали что так можно?
Знали, и часть пакетов уже запихана в requirements.txt. Кто же знал, что с течением времени всё начнёт деградировать?
КБ>Ну допустим виноват pip. Как это по твоему должно работать? pip должен скачать все версии всех пакетов и как-то выбрать из них совместимое подмножество?
Ну, как обычно — сначала качаем метаданные, потом решаем систему неравенств.
Более-менее любой пакетный менеджер способен на подвиги вида
A [installed: 1.0]
B [required: Any, installed: 1.0.4]
D [required: >= 1.0]
C [required: >=2.0.0, installed: 2.0.1]
D [required: < 1.5]
Как-то же они выбирают совместимое подмножество, не так ли?
И если даже мы упираемся в какие-нибудь нездоровые экспоненциальности, то можно не искать точное решение, а просто отрапортовать неудачу. А делать вид, что всё прошло успешно, и оставлять локальную систему в неработоспособном состоянии — ну, такое себе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Константин Б., Вы писали:
КБ>Вообщем посмотрел как прописаны версии пакетов повнимательней. Ты немного наврал.
В каком именно месте я наврал? КБ>Зависимость у контриб прописана как КБ>
Requires-Dist: Sphinx>=5 ; extra == "standalone"
КБ>Чтобы отработало extra нужно имя пакета указывать как sphinxcontrib-applehelp[standalone]. В противном случае условие игнорируется.
Это какое-то шаманство.
Если просто поставить
pip install sphinxcontrib-applehelp==1.0.7
то он стащит свежий sphinx безо всяких standalone.
А если просто сделать
pip install sphinx==4.5.0
то установившийся сфинкс будет неработоспособным. КБ>Соотвественно комманда КБ>
КБ>установит пакеты с непротиворечивыми зависимостями.
Это всё отлично — вопрос: как я должен до этого догадаться? Кстати, вы один из пакетов забыли — так что конкретно эта команда по-прежнему поставит нерабочий сфинкс
КБ>И да оно будет по очереди скачивать все версии пакетов пока не найдет подходящий.
Ну, вот видите — может же, когда захочет. А только что вы были уверены, что сие решительно невозможно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Вообщем посмотрел как прописаны версии пакетов повнимательней. Ты немного наврал. S>В каком именно месте я наврал?
И ему почему-то всё равно на то, что сами эти пакеты требуют sphinx ">= 5.0".
Требуют да несовсем.
S>Это всё отлично — вопрос: как я должен до этого догадаться? Кстати, вы один из пакетов забыли — так что конкретно эта команда по-прежнему поставит нерабочий сфинкс
Это вопроc не ко мне и не к pip.
pip сделал ровно то что ты от него хотел (и больше чем я от него ожидал, это верно) — решил систему неравенств. То что разработчики сфинкса так интересно прописали неравенства — вопрос к ним.
