Часть 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. Надеюсь, именно тебе понравится моя работа =)
