похоже предел: софт использующий Python теперь только докером или подобным

Без подробностей не понятно, почему venv не угодил.

Посмотрел, что за veusz, оказалось, что у них вообще есть пакет для анаконды, тогда совершенно нет причин городить что-то с докером, по-моему.

conda list -e > req.txt
conda create -n <environment-name> --file req.txt

ну или

pip freeze > requirements.txt
pip install -r requirements.txt

В теории да, но помнится при попытке сделать так с pyfa облом настиг на том что надо сбилдить свежий wxwidgets требуемый для нужной версии wxPython. Со всякой около ML-ной приблудой такая же история

около ml-ная приблуда завязана на видеодрайвер, точнее на версию cuda, cuda ставится не в питоновскую виртуальную среду и мало того видяха одна и 2 версии куды одновременно на ней работать не могут и потому проблема с которой тебе и докер не поможет. А вот wxwidgets можно в теории воткнуть куда-то для распространения. Я бы посоветовал в общем случае что лезет в питон класть в питон, а что не питон, распространять классической репой. Ну или если всё предполагается не для разработчика а для юзера то всё в репу класть.

возможно nix решит ваши проблемы с меньшим оверхедом чем докер

Это так не работает. Потому что свежий wxPython требует свежий wxwidgets, которого конечно же ещё нет в репе

с меньшим оверхедом чем докер

увлекаетесь исчислением бесконечномалых?

Кто мешает сделать тебе свою репу? Я об этом и говорю.

Инструменты должны помогать решать проблемы, а не создавать новые.

А с ML там дело даже не в cuda, а в более высокоуровневых штуках типа numpy,tensorflow, torch, каких-либо плагинах или фильтрах, которые тоже частично на питоне, но и сишку покомпилить надо

Я думал докер и придумали из-за питона

Да погоди ты, ща четвёртый питон в бане с пацанами подушу, там не будет никаких зависимостей

даже на вашем «5тб ссд, 128гб памяти и 10гбит интернет» будет операционный оверхед. не всегда дело в числах (хотя и тут можно было бы подвергнуть сомнениям вашу позицию, но да ладно)

даже на вашем «5тб ссд, 128гб памяти и 10гбит интернет» будет операционный оверхед

Какие ваши доказательства?

какие доказательства нужны тому, что запуск через докер не то же самое, что в нативной оболочке? О_о

С numpy проблем никаких нет, если через conda с ним работать которая не только питон позволяет с собой таскать, а вот tensorflow, torch они как раз к куде внутри гвоздями приколочены.

Они и решают. Но просто ты когда свою либу питонячью делаешь, то должен решать проблемы юзера который твою либу будет юзать и для этого делать так чтоб ему не было больно ставить твои сишные бинари. А ты (только не обижайся ты не один такой а скорее большинство людей такие) рассуждаешь чтоб у тебя проблем не было. Тяп ляп, а на всех остальных пофиг. А оно так не работает и в результате имеем то что имеем, а именно кучу геморроя на ровном месте.

Не, он для пыхи и рубистов, когда ещё и субд туда готовую засовывают с конфигами.

Ну в Убунтах pip уже давно как бы намекает, что все, чего нету в репе - только через venv/pipx

 pip install matplotlib
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Это сам pip уже от плохого отучить пытается (надежды на сознательность пользователей бубунты/дебиана нет)

нужной версии wxPython

Не, ну wxPython-то изрядно стабилен, можно и ненужную версию попробовать.

С numpy проблем никаких нет

Если не изменят поведение какой-либо функции. Уж 5 лет прошло, а я всё вспоминаю, когда там запретили при скользящем окне в «хвосты» ряда дописывать среднее оставшейся части «окна» (например, при скользящем среднем можно было до какой-то версии при размере окна 5 в ряде на первом месте ставить среднее от 1-3 чисел, на втором - от 1-4 и т.д., а потом строго NaN ставился и ВСЁ сломалось!) До сих пор у меня глаз дёргается, как вспомню...

Я надеялся цифры увидеть, а вы разговоры разговариваете. Это скучно.

Они и решают.

должен решать проблемы юзера

Хрена се решение. Я хотел программу поставить, а теперь мне надо сопровождать своё расширение дистрибутива и следить, чтобы мои пакеты не пересекались по версиям и не портили жизнь пакетам из других реп. Это куча работы на равном месте без какой либо выгоды.

рассуждаешь чтоб у тебя проблем не было.

Да! Жизнь и так сложная.

а именно кучу геморроя на ровном месте.

А вот с этого места по-подробнее, пожалуйста.

Надо отказываться от софта который не работает без контейнеров. А то у тебя кроме блоатварного питонософта будет ещё блоатварный докер вдобавок к нему.

Надо отказываться от софта …

… и уйти в лес!

… Я хотел программу поставить, а теперь мне надо … Это куча работы …

Прежде чем «поставлять» программы для широкой общественности, надо думать, на чем их писать, какие пакеты третьих лиц использовать, в какой среде это предполагается запускать…) И да - это гораздо сложнее, чем просто сляпать что-то, что работает на своем локальном компе.

И да - это гораздо сложнее,

Ну так я о чём. Жизнь сложная. Инструменты должны облегчать её, а не делать ещё сложнее.

Ну так я о чём. Жизнь сложная. Инструменты должны облегчать её, а не делать ещё сложнее.

Ну, это в идеале…) - в реале же многое развивается через пень колоду, порождается много чего такого, чему лучше бы и вообще не появляться на свет. Многие вещи, которые вроде как упрощают разработку - типа, дружно все вместе наклепаем всего, что можно, и будем потом дружно всем этим пользоваться - неожиданно вызывают тяжелые побочки по части сопровождения и реального использования. Так что, все это надо учитывать и не особо идеализировать IT-действительность - в ней присутствует много откровенного идиотизма.

Как-то очень много слов и никакой конкретики.

Как-то очень много слов и никакой конкретики

А какая тут может быть конкретика?) Для backend-части и для разработки - единственный разумный вариант это использование контейнеров. Для более общего софта - используйте stdlib и как можно меньше всяких дополнительных внешних пакетов, а лучше вообще без них. Гораздо надежнее скопировать нужный код в свой проект.

Из репы или из пипа? А то как бы что не в репе - то в докере, и это не только к питону относится

А какая тут может быть конкретика?

Конкретная. Вот, что имеется в виду под «тяжелые побочки по части сопровождения и реального использовани»? Желательно с примерами, а не общие рассуждения.

используйте stdlib и как можно меньше всяких дополнительных внешних пакетов, а лучше вообще без них. Гораздо надежнее скопировать нужный код в свой проект.

Судя по всему, вы пишите на каком-то доисторическом языке у которого нет нужного инструментария для работы с библиотеками. Отсюда страсть колхозить и велосипедить.

Я не собираюсь здесь дискутировать - по моему, стартовый топик достаточно ясно и четко осветил круг возникающих проблем. Это, в том числе, касается и совета по части разумно-ограниченного использования всяких библиотек и пакетов третьих лиц.

А пишу я на разных языках - какие требуются для решения и сопровождения конкретных задач - в том числе и на Питоне. Так что, угомоните свою понтовитую фантазию)

Я не собираюсь здесь дискутировать

Лор — не место для дискуссий!

стартовый топик достаточно ясно и четко осветил круг возникающих проблем.

И заодно показал метод решения.

разумно-ограниченного использования всяких библиотек и пакетов третьих лиц.

А вместо этого предлагается неразумно-безграничное переизобретение велосипеда. Удачи вам в трудах.

И заодно показал метод решения

Так я и не возражаю. Docker это конечно не для рядовых юзеров - для них есть более адекватные решения типа snap-пакетов и пр. Но это далеко не всех и не всегда устраивает. Так что, я просто высказал свою точку зрения.

… возьмите тот же Docker Compose - первые версии были написаны на Питоне, а потом проект ушел в Golang. В конечном итоге так оказалось удобнее.

Хрена се решение. Я хотел программу поставить, а теперь мне надо сопровождать своё расширение дистрибутива и следить, чтобы мои пакеты не пересекались по версиям и не портили жизнь пакетам из других реп. Это куча работы на равном месте без какой либо выгоды.

тому кто твою программу которую ты ставишь вот это надо было делать, ну и если ты свой результат дальше хочешь распространять, то и тебе тоже.

А вот с этого места по-подробнее, пожалуйста.

у челиков куча времени и желания писать опенсорсные проги/либы, запихивать их в pip/anaconda/докер/флетпаки/снапы, но поднять репу даже в убунтовском лаунчпаде или вообще у суси у которых есть аналогичный инструмент под все дистрибутивы, на это времени нет, потому как оно же надо разобраться 1 раз как rpm/deb пакеты работают и потратить на это 1 день своей жизни. Но челикам просто код высрать хочется с 0 поддержкой и отсутствием мыслей о юзерах их кода. Когда чатгпт таких заменит станет только лучше.

тому кто твою программу которую ты ставишь вот это надо было делать, ну и если ты свой результат дальше хочешь распространять, то и тебе тоже.

Не было у бабы заботы, купила баба порося.

у челиков куча времени и желания писать опенсорсные проги/либы, запихивать их в pip/anaconda/докер/флетпаки/снапы, но поднять репу даже в убунтовском лаунчпаде или вообще у суси у которых есть аналогичный инструмент под все дистрибутивы, на это времени нет,

Типа да.

Притянуть для запуска фигнюшки вместо только лишь зависимостей целый дополнительный юзерспейс — не бесконечно малый интерфейс. А их еще и настраивать, эти чруты, даром что гламурные.

Потому всё просто на самом деле - не надо пользоваться софтом/либами от челиков которым пофиг на юзеров. У них обычно всё говёного качества, не только способ установки. Последний раз смотрел на C# проект такой на гитхабе, который был заявлен как работоспособный (по факту крашился на страте а как я исходники посмотрел стало понятно что челик тупо заглушки функций сделал, а код написать в них не написал, видимо просто работу искал чтоб код какой-то со звёздами которые сам себе и накрутил показать херкам, они один хрен не разберутся в нём если установка подразумевает компиляцию с подтягиванием руками нужных библиотек).

Потому всё просто на самом деле - не надо пользоваться софтом/либами

Т.е. вы пропагандируете подход не только увеличивающий трудозатраты для разработчика, но и снижающий доступность программ для пользователя. Да, товарищ, с таким маркетингом вы бедуину в Сахаре стакан воды не продадите.

Опять рассуждения вместо фактов. Ещё и косноязычный как будто пьяный писал. Сегодня воскресенье, можно и расслабиться, но ведь ещё едва полдень наступил. Не слишком ли вы торопитесь?

https://www.youtube.com/watch?v=S4II_1Nyu8U

У меня нет слов. Продолжай гореть как и ТС.

как (не всем понятное) следствие упомянутых проблем :

Python любой версии и тюнинга, надо вынимать из зависимостей системы. То есть системные программы/демоны/сервисы не должны зависить от питона и его либ. Иначе тот-же systemd через пару лет выйдет колом и выпуск обновления дистра станет лютой попоболью.

пока-что проблемы возникают в прикладном софте, но они стремятся уйти в системный. Сейчас проблемы можно обойти докерами/снапами/аппимаджами, а далее уже нет.

TrueЪ по ссылкам не ходят. А уж тем более на ютуб. У вас вообще совесть есть?

Факт: докер — костыль. Костыль, вызванный импотентностью недоПМ, не позволяющим просто поставить софт с нужными зависимостями (см. тред выше, где язычковый недоПМ питона ожидаемо не умеет в разрешение нативных зависимостей), «решающий» вопрос, таща в систему еще один юзерспейс. Тут не нужны рассуждения, это нольходовочка. Квадратно-гнездовой ПМ не справляется с помойкой в /? На тебе новый /.

Мне кажется, вы заходите не с того конца. Система, способная развалиться от любого чиха, это плохо спроектированная система. Всё остальное уж следствие.

Оценочные суждения. К тому же голословные. А казалось бы — простейшее дело: запустил расчёт в докере и без него и сравнил время работы и потребление памяти. Две цифры написать лень, а пустословить хуже Льва Толстого не лень. Подозрительно это.

как (не всем понятное) следствие упомянутых проблем :

Python любой версии и тюнинга, надо вынимать из зависимостей системы. То есть системные программы/демоны/сервисы не должны зависить от питона и его либ. Иначе тот-же systemd через пару лет выйдет колом и выпуск обновления дистра станет лютой попоболью.

Здесь, я думаю, для более-менее мейнстримных дистрибутивов проблемы маловероятны. Все, что находится в репозитории, должно быть совместимо между собой и быть работоспособным даже после обновлений, иначе пользоваться таким дистрибутивом вряд ли стоит.

Для стороннего софта, по понятным причинам, никто ничего не гарантирует. Что мы сегодня и наблюдаем. И Питон здесь просто один из ярких примеров в силу своей популярности и как такового отсутствия спецификации необходимого для софтины рантайма