Лучший способ распространения СПО на Python для разных ОС?

Docker не нужен. Блобы тем более. Пакетные манагеры для языка идея ущербная. Поэтому только в исходных кодах, формат не важен.

 в виде исходников, git clone
 в виде исходников, архив

В виде пакета в репозитории дистрибутива.

Расшифровку можно?

Расшифровку чего именно?

Заголовка, СПО

Свободное программное обеспечение

Ого, какая категоричность!

Можно поинтересоваться, как без докера организовать, например, CI/CD? Разработку большого (> 300,000 KLOC) проекта, состоящего из нескольких сервисов (как на Python, так и пачки SQL, NoSQL и прочей вспомогательной инфраструктуры), с которым работают сотни разработчиков, тестеров, и т.д.?

Тут скорее он не нужен конечным пользователям(лишние сущности - зло) и, соответственно, как способ распространения, а разработчик может использовать что хочет. Я возможно не очень точно выразился. Речь в опросе как раз про конечный результат.

Лучший способ распространения — это несколько способов распространения сразу, на выбор пользователя. Но если уж выбирать один, то «в виде исходников, git clone». Хотя pip как дополнение очень уж просится. Ну и да, зависит от ситуации, потому что иногда конкретно для винды бывает проще отдать в виде установщика, или одного бинарника.

Есть всего два незашкварных способа распространения софта на python: в сорцах и в родном для твоего дистрибутива виде. Как можно было один пропустить в опросе — ума не приложу.

И исходники, и пакеты есть в вариантах.

Там неправильные пакеты, за них рука не поднимется голосовать.

deb и др. - Linux

Чем не устраивает?

Допустим, у меня дебиан. Мне нафиг не упал .deb-пакет условного numpy на numpy.org, мне нужен numpy в репозиториях дистриба.

А где мультивыбор?

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

Всё-таки добавлю мультивыбор, для кого-то одинаково хорошими могут оказаться оба способа.

Для обычных людей только пакеты со всеми зависимостями: rpm/deb. Архив и git clone для остальных дистрибутивов linux и нестандартных случаев. Всё остальное это уже непонятно для кого. Docker? Серьёзно?

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

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

Но мне кажется докер это не про питон а именно про сложные системы.

СПО = Специальная Питонная Операция

С этой кучей технологий получается зоопарк механизмов обновления. У нас уже был период, когда СПО тягали отовсюду по кусочкам, потому что никакой централизации не было — не понравилось. Пакетные менеджеры сделали, стало легче. Это случилось, фактически, на заре дистростроения, т.е. проблема была осознана и решена практически сразу же. И вот-те нате, снова здорово: давайте плодить сущности. Часть системы будет обновляться через DEB/RPM, часть через pip, часть через конду, ещё сверху докер, флэтпак, снап, поперчить, посолить, и в этом винегрете жить.

Заголовка, СПО

Санитарно-производственные отходы. Питон же.

pip'ом или исходниками, если не хочешь в систему тащить ставь в виртуальное окружение. Ток не в докере. Еще и докер в систему тащить.

в виде пакетов (msi, установщик в exe - Windows, deb и др. - Linux)

Юзерфрендли.

образ Docker и др.

Удобно для сервисов и не надо вручную суппортить экосистему питона с его версиями и зависимостями.

Я не пользуюсь пакетными менеджерами, отличными от pacman. Что я делаю не так?

не стоит писать СПО на Python для других людей

Сам не использую Python. И другим не советую. Жаль, что его полностью из своей системы не получается выпилить.

А питон может сам себя на ходу переписывать? Ну сгенерить файлик на питоне, подключить и выполнить? А если так – как его можно скомпилировать в си?

Да хоть бы, простихосспади, и pacman. Всё дело б-гоугодное.

Сколько хороших и добрых людей на ЛОРе!

Вынужден признать, что Pypi (pip) на текущий момент является самым универсальным кроссплатформенный способом распространения.

В питоне есть инструкция eval так-то. Но у меня есть предположение, что компилированный питон её не поддерживает.

• в виде пакетов (msi, установщик в exe - Windows, deb и др. - Linux)
• pip, .whl с публичного или частного сервера
• в виде исходников, git clone
• в виде исходников, архив

Вот это слишком радикальная позиция:

не стоит писать СПО на Python для других людей

Если ты запустил скрипт в консоли и ждешь, пока он отработает, то скорость исполнения не критична.

Интерактивный CLI-софт на моей памяти не был тормозным.

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

Вебня? Там, где нужна производительность, используют Java, а то и CGI-бинарники. Выкидывать Python, потому что он медленнее сишечки, и использовать другой скриптовый язык – странно и непоследовательно.

свой вариант: понятия не имею. Пробовал системным менеджером пакетов, пробовал pip'ом, пробовал тупо через curl/wget... Они б там сами бы в своем бардаке разобрались бы...

Напиши, плиз, разрабам, чтобы выпилили его из своих поделок:

% sudo pacman -Rsn python
[sudo] password for admin:         
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing python breaks dependency 'python' required by audacity
:: removing python breaks dependency 'python' required by dbus-python
:: removing python breaks dependency 'python' required by gdb
:: removing python breaks dependency 'python' required by gdb-common
:: removing python breaks dependency 'python' required by hplip
:: removing python breaks dependency 'python' required by inkscape
:: removing python breaks dependency 'python' required by kig
:: removing python breaks dependency 'python' required by libkiwix
:: removing python breaks dependency 'python' required by libreoffice-still
:: removing python breaks dependency 'python' required by mono
:: removing python breaks dependency 'python' required by python-appdirs
:: removing python breaks dependency 'python' required by python-beautifulsoup4
:: removing python breaks dependency 'python' required by python-cachecontrol
:: removing python breaks dependency 'python' required by python-cairo
:: removing python breaks dependency 'python' required by python-certifi
:: removing python breaks dependency 'python' required by python-chardet
:: removing python breaks dependency 'python' required by python-coverage
:: removing python breaks dependency 'python' required by python-cssselect
:: removing python breaks dependency 'python' required by python-distro
:: removing python breaks dependency 'python' required by python-filelock
:: removing python breaks dependency 'python' required by python-gobject
:: removing python breaks dependency 'python' required by python-idna
:: removing python breaks dependency 'python' required by python-lockfile
:: removing python breaks dependency 'python' required by python-lxml
:: removing python breaks dependency 'python' required by python-msgpack
:: removing python breaks dependency 'python' required by python-numpy
:: removing python breaks dependency 'python' required by python-packaging
:: removing python breaks dependency 'python' required by python-pillow
:: removing python breaks dependency 'python' required by python-pyserial
:: removing python breaks dependency 'python' required by python-six
:: removing python breaks dependency 'python' required by python-soupsieve
:: removing python breaks dependency 'python' required by python-urllib3
:: removing python breaks dependency 'python' required by python-zstandard
:: removing python breaks dependency 'python' required by reflector
:: removing python breaks dependency 'python' required by serioussam-vk
:: removing python breaks dependency 'python' required by smbclient
:: removing python breaks dependency 'python' required by steam
:: removing python breaks dependency 'python' required by virtualbox

+ в виде исходников, архив

+ в виде пакетов (msi, установщик в exe - Windows, deb и др. - Linux)

+ не стоит писать СПО на Python для других людей

Пакеты в дистре. Только так. pip говно, все остальное тоже.

Git + pip конечно обязательно. Установщики, дистрозависимые пакеты опционально

Воздушно-капельным…

Распространение пестона – это боль. Лучший вариант, когда оно есть в реках или flatpak.

Вот это слишком радикальная позиция:

не стоит писать СПО на Python для других людей

Это клоунада от модеров, я такого не писал.

А питон может сам себя на ходу переписывать?

Нет.

Ну сгенерить файлик на питоне, подключить и выполнить? А если так – как его можно скомпилировать в си?

Вообще, под винду раньше я использовал py2exe. Это вообще ни как не С, но довольно удобно.

Видимо, большинство, кто отвечал, не понимают, что есть куча инсталляций Linux без доступа в Интернет. Бывает, что deb не установишь, потому чото зависимости нужны, а интернету нету.

Поэтому никакие pip, никакие исходники (как вы их в рабочий вид приводить будете?) не канают.

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

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

Современные программисты (как это ни странно) идут той же дорогой, поэтому ценят в первую очередь простоту и «юзабилити».

Был смешной пост от автора brew (такой пакетный менеджер для MacOS), который жаловался что гугловые разрабы постоянно пользуются его софтом но никогда и ни за что не возьмут его самого на работу в Гугол.

Надо думать о пользователях.

Верно, надо избегать питон. Ну или всякая вебня которая без инета и работать не станет (типа ytdl) - тут можно понять, ведь из-за особенностей веба они вынуждены очень быстро обновляться и на нормальном прод-языке это было бы затруднительно.

Это клоунада от модеров, я такого не писал.

Это не клоунада, добавили вполне важный вариант который набрал голосов аж на четвёртое место.

Кто понимает про Python то понятно выберет whl.

P.S. Можете мне объяснить разницу между

в виде пакетов (msi, установщик в exe

и

сборка в pyinstaller и др., один бинарник (.exe, .AppImage и др.)

и

сборка в pyinstaller, cx-freeze и др., архив

Верно, надо избегать питон.

Правильно. А теперь попробуйте удалить из своего дистра python.

Я уже пробовал. Глубоко сидит :(

Хотя в последнее время (то ли с переходом на debian 11, то ли ещё из-за чего-то) кажется ситуация чуть улучшилась. Из реально нужного от него зависят небольшие огрызки dpkg/apt, всякие принтерные штуки (пакеты с названиями «printer-driver-*» и hplip), gdb, dkms и всякое медиа включая mplayer, mpv и yt-dlp. Ещё samba, но она не нужна (не помню зачем поставил, не пользовался ни разу т.к. виндошар у меня в локалке нет, наверно надо снести её).

Мне кажется что dpkg/apt вполне за обозримое время можно переписать на работу без питона (а вот внедрить это в официальный дебиан релиз - намного сложнее). gdb очень хотелось бы избавить тоже от питона, но там скорее всего всё сложно. Насчёт остального не знаю, кроме yt-dlp - там очевидно поможет только переписывание с нуля и дальнейшая самостоятельная поддержка всего, чего никто делать очевидно не будет.

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