Как перестать беспокоиться и установить Python-проект другу под Windows

Итак, вы закончили свою первую версию опенсорс проекта на Питоне, выложили её на Гитхаб, и даже написали честный ридми: «Требуется Python 3.10, поставьте зависимости через pip install -r requirements.txt«.

И... через какое‑то время вам звонит пользователь друг с вопросом: «Слушай, интересный проект, а как его под Windows поставить?»

Собственно, с этого момента у вас есть 3 варианта:

  1. Попытаться сэкономить всем время и попробовать упаковать ваш проект в EXE‑файл через утилиты типа pyinstaller или Auto PY to EXE. Минус: при сколь‑нибудь сложных зависимостях нужно будет ковыряться довольно долго, чтобы заставить EXE заработать. Второй минус: как вы думаете, на кого ляжет почетная обязанность собирать EXE‑шники после каждого апдейта кода?

  2. Попытаться объяснить другу, что такое python, GIT и как всё это поставить. Минус: возможны проблемы в отношениях с другом:))) (Вариант: поставить всё самому через дистанционный доступ, но он требует слишком много времени если пользователей друзей больше 5)

  3. Дописать под себя набор BAT‑файлов, о которых пойдет речь в статье, и которые:

    1. ставят сами Python и GIT в локальную папку проекта (в стиле conda);

    2. выкачивают свежую версию с Гитхаба (а также апдейтят её при необходимости);

    3. ставят нужные зависимости;

    4. можно прописать несколько сценариев запуска приложения;

    5. установленный проект можно перемещать в другие папки и между компами.

Как я эти батники нашел

Есть такой интересный опенсорс проект, который позволяет запускать текстовые нейросети на локальном компьютере с веб‑интерфейсом: https://github.com/oobabooga/text‑generation‑webui

Проекты с нейросетями, как правило, это проекты с очень большим числом нетривиальных зависимостей. Например:

И я был сильно удивлен, когда нашел проект от того же пользователя под названием one‑click‑installers, который решал все эти проблемы установки буквально в несколько BAT‑файлов.

Собственно, я его установил (все заработало с первого раза), разобрался в BAT‑файлах, и они меня так впечатлили своей компактностью, что я даже достаточно быстро сделал подобный компактный инсталлятор для своего голосового помощника Ирины.

Как это работает и как это настроить

В качестве базового проекта рекомендую взять мой инсталлятор, а за нетривиальными случаями обращаться к оригинальному one‑click‑installer.

Итак, есть два основных файла:

install делает следующее:

  1. Скачивает проект micromamba (компактная замена conda). (Вначале выводится предупреждение — путь не должен содержать пробелов и нелатинских букв/цифр.)

  2. Устанавливает указанные пакеты (в частности, я указываю python3.10 и git; в моем BAT‑файле есть еще выбор, установить ли тяжелый torch для Silero TTS, но вы можете этот выбор убрать) в installer_files.

  3. Активирует окружение

  4. Если репозитория вашего проекта ещё не существует — клонирует его с Гитхаба; если уже существует — пытается обновить с помощью git pull.

  5. Устанавливает или обновляет зависимости через call python -m pip install -r requirements.txt --upgrade. (У меня используются кастомные зависимости в call python ‑m pip install ‑r requirements_exe_runner.txt ‑upgrade, так что не забудьте поправить для своего проекта)

Собственно, после install в идеале наш проект полностью готов к работе.

run предельно простой:

  1. Он инициализирует окружение с нужными зависимостями

  2. Запускает нужный питон‑файл через call python run.py (или что вы там укажете)

Также в проекте существует micromamba‑cmd.bat, который позволяет в интерактивном режиме зайти в текущее окружение и что‑то там подправить (например, поставить новые зависимости ручками если сильно нужно).

Переносимость

Установка переносимая; но после переноса в другое место будет выдавать ошибку «Micromamba not found» — потому что сформированные BAT‑файлы Micromamba содержат абсолютные пути.

Для решения проблемы после переноса нужно удалить все BAT‑файлы из installer_files\mamba\condabin и запустить run.bat — BAT‑файлы будут перегенерированы.

Выводы

install.bat выполняет основную часть установки, ставя зависимости через Интернет, позволяет быстро обновлять проект до последней Git‑версии, и занимает всего 90 строк кода.

Вот я с ним поработал и могу сказать — поправить его под свой проект занимает где‑то полчаса‑час (ну, вместе с тестированием мелочей, конечно).

По‑моему, очень удобно.

@janvarev
13.04.2023 14:45 UTC
Первоисточник

Комментарии

@apro
13.04.2023 09:50 UTC
+8

Второй минус: как вы думаете, на кого ляжет почетная обязанность собирать EXE-шники после каждого апдейта кода?

На "GitHub Actions" ?

@janvarev
13.04.2023 09:57 UTC
0

Да, есть такой вариант, только этот CI/CD надо будет настраивать и поддерживать - опять же вам :))

(А вообще формирование EXE не очень удобно при сложных зависимостях или каких-нибудь опциях/моделях, лежащих в отдельных папках и файлах)

13.04.2023 10:00 UTC
+6

Это нужно сделать один раз + при этом можно добавить выполнение тестов после сборки.
И таки да, это придется делать вам, как автору и разработчику проекта :-)

13.04.2023 10:07 UTC
-6

Я напоминаю: автор опенсорс проекта обычно НЕ получает денег за свою работу, поэтому читать, "что еще автор должен сделать, чтобы пользователям было удобнее" ну... не очень приятно (Автор относительно известного проекта получает такие сообщения постоянно, и их необходимо приоретизировать - как баги или фичи)

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

Но если вам хочется сделать вариант с CI - вы всегда можете сами дописать этот воркфлоу или форкнуть проект :)

13.04.2023 10:16 UTC
+3

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

Вы зря рассматриваете мой комментарий как нападки на вас с точки зрения расширения объема задач. Просто решил вам напомнить, что в автоматизации есть и свои плюсы.

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

Удачи вам!

13.04.2023 10:39 UTC
-2

Просто решил вам напомнить, что в автоматизации есть и свои плюсы.

Люди, которые не знают, что в автоматизации есть свои плюсы, обычно не пилят опенсорс-проекты :) Так что странно, что вы мне это хотите напомнить :)) и да, к сожалению, наладка CI выглядит, как расширение объема задач.

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

Спасибо за беспокойство, но пользователям я также напоминаю, что в опенсорс проекте я стараюсь делать то, что мне интересно, а для остального есть форк/пуллреквест (хотя считаю, что обязанность ревьювить у автора проекта есть, да).

Пока моих пользователей это устраивает, так что всё хорошо :)

14.04.2023 02:30 UTC
0

Вы уверены, что сделать ВАТ файлы проще, чем CI pipeline?

14.04.2023 07:02 UTC
-1

CI pipeline не всегда выход - еще раз, попробуйте собрать какой-нибудь нетривиальный Python-проект в EXE-файл. Там всё время что-то отваливается, и надо потратить немало времени на отладку.

BAT ставит в чистом виде Питон, Гит и собственно проект как он задумывался.

@
13.04.2023 10:19 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@janvarev
13.04.2023 10:46 UTC
0

Честно говоря, не тестировал это ограничение.

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

@
13.04.2023 20:31 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@AlexanderDem
13.04.2023 12:07 UTC
+3

еще очень удобно использовать WinGet
https://www.microsoft.com/en-us/p/app-installer/9nblggh4nns1#activetab=pivot:overviewtab

например example.bat:

winget install -e --id Git.Git
winget install -e --id=Python.Python.3.10
winget install -e --id=Microsoft.VCRedist.2015+.x64

и повесить выполнение bat скрипта на кнопки в Visual Studio Code (плагин Action Buttons)

winget install -e --id Microsoft.VisualStudioCode
code --install-extension seunlanlege.action-buttons

.vscode => settings.json

"actionButtons": {
"reloadButton": null,
"loadNpmCommands": false,
"commands": [
{
"name": "ExampleButton",
"singleInstance": true,
"color": "deepskyblue",
"command": "example.bat",
},
]
}
}

@janvarev
13.04.2023 12:15 UTC
+1

Интересно, посмотрю. Но если правильно понимаю, он не решает вопросов установки Python пакетов в окружении рядом собственно с папкой проекта (а такое нужно, если несколько проектов, чтобы там зависимости не пересекались)

13.04.2023 12:35 UTC
0

да, скорее всего не решает

13.04.2023 13:00 UTC
0

но можно явно указывать переменную среды, в bat скрипте, что то типа:

set PYTHON=%HOMEDRIVE%%HOMEPATH%\AppData\Local\Programs\Python\Python310\python.exe

@dyadyaSerezha
13.04.2023 12:28 UTC
0

Насчёт первых двух шагов скрипта install - если они уже ввполнены, то будут ли выполняться опять или установки будут пропущены? Что будет, если появится новая версия Python 3.10?

@janvarev
13.04.2023 12:50 UTC
0

Не тестировал, если честно. Надо смотреть.

@Andrey_Solomatin
13.04.2023 12:28 UTC
+2

Дочитал до батников и бросил.

Дома работаю с виндой, Пайчарм коммунти.

Pip уже не ставил руками много лет, вроде он уже в установщик питона входит.
Пайчам уже давно предоставляет удобный способ создавать виртульное окружение, где точно есть пип. Так что с "pip install -r requirements.txt" обычно проблем нет. Проблемы обычно, с тем, что надо собирать из С++ исходников. Но популярный библиотеки можно просто скачать. Хотя с этим тоже уже давно не сталкивался.

Питон на винде стал намного более удобным чем 10 лет назад.

@janvarev
13.04.2023 12:51 UTC
0

Это для друга, у которого нет Pycharm и который вообще не разработчик ни разу )

Для разработчика обычно проблем нет.

13.04.2023 19:18 UTC
0

Интересный друг, который знает про github, но не знает как установить python...

@Krouler7
13.04.2023 13:47 UTC
+2

Ожидал применение docker и/или docker-compose.

Что может быть проще для друга, чем пара-тройка команд, описанных на GitHub, и несколько дополнительных файлов в репозитории - и все, у друга работоспособный проект? Причем тут не важно на какой системе. На Windows, например, у Docker есть удобный UI ко всему прочему.

Деплой можно даже автоматизировать - написать тот самый батник с чередой команд для Docker. И теперь вместо цепочки файлов .bat есть один и установленный Docker.

@janvarev
13.04.2023 13:51 UTC
+1

Я промолчу...

Докер лучше всего работает, если у вас проект с сетевым интерфейсом (сокеты или http разных вариантов).

Что делать, если нужен доступ к микрофону машины? Или если хочется банально запустить Win GUI интерфейс?

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

13.04.2023 14:05 UTC
0

Что делать, если нужен доступ к микрофону машины

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

Да, это дополнительные усилия. Но в посте ситуация:

И... через какое-то время вам звонит пользователь друг с вопросом: "Слушай, интересный проект, а как его под Windows поставить?"

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

13.04.2023 14:10 UTC
0

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

Также желательно, чтобы отладка этого инсталлятора не убивала кучу времени разработчика. Вот например это: "С другой стороны, можно обеспечить передачу информации в контейнер по сокету. " - это явное напряжение разработчика ради соответствие экосистеме докера. Оно не дает никакой новой функциональности пользователю, а разработчика напрягает.

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

@Andrey_Solomatin
13.04.2023 14:36 UTC
+3

Я как-то ставил докер на виндоус, помню, что было как-то неудобно.

@Tanner
13.04.2023 15:57 UTC
+1

Можно установить цыгвин, запустить баш и делать всё как в линуксе.

@GBR-613
13.04.2023 19:02 UTC
-1

Python на Cygwin плохо работает. К тому же Cygwin занимает много места.

14.04.2023 05:10 UTC
0

Как плохо? Сколько это – «много»?

@dbax
14.04.2023 06:38 UTC
+1

а чем wsl не устраивает?

14.04.2023 06:56 UTC
0

Ну, если нормальный Linux-дистрибутив чем-то не устраивает, то, наверное, тем же может не устраивать и Линукс в виртуалке, чем WSL 2 и является.

Например, может быть существенным тот факт, что тулзы под Cygwin собирают Windows-нативные исполняемые файлы, которые можно использовать и без Cygwin.

@shoorick
15.04.2023 06:48 UTC
0

Я цыгвином баловался лет 15 назад, но тогда ещё WSL не было. Пару лет назад, когда виндовой коллеге надо было что-то линуксовое запускать, настроил ей WSL — уже тогда оно работало.

@vova9110
15.04.2023 00:57 UTC
0

Ох уж эти питонщики, ленятся компилить экзешники. Я с питоном по-стольку по-скольку, но неужели, долбаться дольше, чем с CMake?