Здравствуйте, Константин Б., Вы писали:
КБ>Был в свое время ментейнером 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 сделал ровно то что ты от него хотел (и больше чем я от него ожидал, это верно) — решил систему неравенств. То что разработчики сфинкса так интересно прописали неравенства — вопрос к ним.
