Часть 1: Боль от использования Pinokio
Все началось с простого — в один день я узнал о Pinokio, когда хотел поставить себе один популярный репозиторий с гитхаба — facefusion, но мне было лень самому ставить питон и CUDA на систему, поэтому я поспрашивал друзей о том, как они выкручиваются из такой ситуации. Они мне рассказали о Pinokio и я подумал, что он вполне может решить мою настолько тривиальную задачу. Скачал, установил. Оболочка красива — спору нет. Но для того чтобы поставить самый легковесный репозиторий — он стал ставить Miniconda, кучу пакетов, что весьма долго и нудно. А главное кушает место на диске. Но это полбеды. Интерфейс то тоже не быстрый — имеет лаги. А это весьма неприятно =(
Отсюда и выливается боль от использования, а аналогов данной приблуде нет, либо есть, но они не популярны.
Часть 2: Почему так больно? И правда, что это не полноценный open-source?
Человек я хоть и ленивый, но я никогда не против посмотреть на исходный код программы, которую использую — ведь всегда интересно, а почему она работает так?
Если мы перейдем на официальный репозиторий данной программы, то увидем, что код в целом есть. И видно, что приложение написано на Node JS. Но давайте копнем глубже? Посмотрим на package.json (приведены первые 24 строки):
"name": "Pinokio",
"private": true,
"version": "3.19.92",
"homepage": "https://pinokio.co",
"description": "pinokio",
"main": "main.js",
"email": "cocktailpeanuts@proton.me",
"author": "https://twitter.com/cocktailpeanut",
"scripts": {
"start": "electron .",
"pack": "./node_modules/.bin/electron-builder --dir",
"eject": "hdiutil info | grep '/dev/disk' | awk '{print $1}' | xargs -I {} hdiutil detach {}",
"l": "docker run --rm -ti -v $PWD:/project -w /project -e SNAPCRAFT_BUILD_ENVIRONMENT=host -e SNAP_DESTRUCTIVE_MODE=true electronuserland/builder bash -lc 'rm -rf node_modules && npm install && npm run monkeypatch && ./node_modules/.bin/electron-builder install-app-deps && ./node_modules/.bin/electron-builder -l'",
"mw": "rm -rf node_modules && npm install && npm run monkeypatch && ./node_modules/.bin/electron-builder install-app-deps && ./node_modules/.bin/electron-builder -mw && npm run zip",
"build2": "npm run l && npm run mw",
"dist": "npm run monkeypatch && ./node_modules/.bin/electron-builder install-app-deps && export SNAPCRAFT_BUILD_ENVIRONMENT=host && export SNAP_DESTRUCTIVE_MODE='true' && ./node_modules/.bin/electron-builder -l && npm run zip",
"dist2": "npm run monkeypatch && export USE_SYSTEM_FPM=true && ./node_modules/.bin/electron-builder install-app-deps && export SNAPCRAFT_BUILD_ENVIRONMENT=host && export SNAP_DESTRUCTIVE_MODE='true' && ./node_modules/.bin/electron-builder -mwl && npm run zip",
"zip": "node script/zip",
"monkeypatch": "cp temp/yarn.js node_modules/app-builder-lib/out/util/yarn.js && cp temp/rebuild.js node_modules/@electron/rebuild/lib/src/rebuild.js",
"postinstall2": "npm run monkeypatch && ./node_modules/.bin/electron-builder install-app-deps",
"fix": "brew install fpm"
},Давайте подробнее посмотрим на секцию scripts. Что мы увидим? Что приложение написано на electron (привет лаги и большой вес!). И какие‑то весьма странные манки‑патчи, не так ли? Это двигает на следующий шаг рассмотреть main.js:
const Pinokiod = require("pinokiod")
const config = require('./config')
const pinokiod = new Pinokiod(config)
let mode = pinokiod.kernel.store.get("mode") || "full"
//iprocess.env.PINOKIO_MODE = process.env.PINOKIO_MODE || 'desktop';
if (mode === 'minimal') {
require('./minimal');
} else {
require('./full');
}А собственно, где весь src? Где вся логика? А ее и нет в помине, ведь все что на гитхабе — это просто красивый враппер над уже скомпилированной библиотекой, исходный код которой закрыт. Разве это не странно? Проект позиционирует себя как open‑source, а по факту является source‑available. Исходного кода нет, но вы держитесь. А еще разве не странно, что дата релиза кода и даты релизов скомпилированных версий весьма разняться? Мне кажется это достаточно странным. Можете взглянуть и сами на это:
Часть 3. Где все аналоги? Почему все так плохо?
Аналоги может и есть в такой же красивой обертке — но они весьма непопулярны и их достаточно трудно найти. Тогда остается либо идти искать портативный вариант (у репакеров, например), либо ставить самому это руками или взять докер и задеплоить. Но докерфайлы есть не всегда, как и время с желанием у простого пользователя разбираться в установке из командной строки или докера. Поэтому, такую проблему иногда решает и сам автор репозитория, например ComfyUI — автор выпускает готовые окружения с CUDA, питоном и возможностью обновления через батник. Весьма удобно, не так ли? Но как можно было бы решить данную проблему, чтобы сохранить всю идейность? Чтобы просто скачать один.exe, запустить его, поставить то что нужно, поработать. Надоело? Просто снес одну папку и все, больше не надо нигде лазить по системе... Именно с такой мыслью я делал свой пет‑проект — PortableSource, который должен решить все возникшие вопросы.
Часть 4 Что это за зверь такой — PortableSource?
В чем, собственно, плюс был делать что‑то свое? Все весьма и весьма просто. Тут заложена простая идеология: юзеру нужно кликнуть всего‑лишь пару кнопочек, чтобы получить результат и работать с ним.
Как это было реализовано на практике? Изначально идея была проста: возьмем Miniconda, напишем простую логику обработки окружений и все будет чики‑пуки. Это могло годиться лишь на черновой проект, ведь у Miniconda (и ее аналогов, например micromamba) есть один жирный минус: они не портативны. Ты просто не можешь взять и перенести папку с проектом на другой диск — ведь у тебя выставлены статичные пути в батниках активации! А еще один достаточно неприятный минус — конда и ее производные оставляют свои данные не только в папке установки. Это может быть кэш, принятие ToS и так далее. И главный минус миниконды был в том, что написана она на питоне и весьма медленна. Как его можно было обойти? Взять micromamba. Но и тут всплыл жирный минус, о котором я говорил — отсутствие портативности. Тогда, собственно, что можно сделать, дабы достичь максимальной портативности? Собственный менеджер! Идея проста как пареная репа: для полностью рабочего окружения нужно всего‑то 4 пакета: CUDA, python, git и ffmpeg. У них есть портативные версии (кроме CUDA) и они вполне легко переносятся между дисками. А теперь минутка душноты для тех, кто хочет знать весь механизм создания среды:
Первый и самый важный этап состоит в том, чтобы определить видеокарту. Всего есть 3 условных класса для работы: GTX 10–16, RTX 20xx — относятся к классу для работы с CUDA 11.8, то есть Turing и Pascal используют свою «родную куду» и полностью себя раскрывают. Rtx 30xx — Ampere. CUDA 11.8 будет медленной, не так ли? А 12.8 избыточна по функционалу. Потому выбор пал на 12.4. Ну и Blackwell и Ada — 50xx и 40xx, конечно же, 12.8 чтобы полностью раскрыть свою мощь. Что насчет питона? Все вполне просто: мы скачиваем один раз чистую версию, в которой установлен лишь pip. А потом в сопоставление репозитория по имени создаем свою изолированную среду, на основе того самого чистого пакета. Мощно, быстро и сердито! А главное — легко и портативно.
Часть 5. Все красиво! А где потестить?
Потестить можно вот тут. Самое удобное — просто скачать portable версию. Она не устанавливается в систему и запускается просто два раза кликнув по ней. А для тех кто хочет подробнее узнать о коде, можно посмотреть вот тут: GUI, CLI. Надеюсь, именно тебе понравится моя работа =)
