https://github.com/KOLANICH/prebuilder.py . Заранее предупреждаю, о нюансах:

1. Я - большой любитель переписывания истории, и этот initial commit много раз переписывался (как и в остальных моих проектах), и ещё много раз будет переписан. Это экономит на хранении никому не нужной истории. PRы почти всегда можно перекинуть на несвязанную историю путём экспортирования в патчи git format-patch -сколько_надо, и затем git am.

2. Проект зависит от других моих проектов и либ, а также от множества либ других людей. И что ещё хуже, от моих форков полузаброшенных либ, авторы которых свои проекты фактически не мейнтейнят.

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

4. Проект зависит от одной из моих либ и инструментов и интеграции одной из фич в пакетный менеджер. Эта фича - экспорт некоторой метаинформации aptом при обнавлении и установке пакетов. Это необходимо для эффективного инвертированного индекса информации о пакетах. Он нужен для эффективного поиска зависимостей среди пакетов. Сейчас в aptе она хранится в текстовом виде и dpkg -S считывает её всю, и потом выбрасывает. Нам же такая производительность неприемлима. Сейчас индекс обновляется ручным вызовом комманды. Но это можно автоматизировать, сделав построение индекса при первоначальной установке пакета, а потом обновление инфа только об изменрвшихся пакетах. Для прокидывания всего этого великолепия в питон была создана отдельная либа, но она недоделана - руки не дошли. И последние измененря даже не опубликованы. Так что пока команда вызывается ручками, исполныется 20 секунд, а если не сделать, то при автодетекте зависимостей сборка может вылететь с ошибкой, что такой зависимости нет в индексе. Так вот, мои патчи в apt для пробрасывания всей необходимой информации не то что не слиты, даже не отревьювены.

5. Инструмент изначально был задуман с прицелом на CI. Логика такая: если разраб оригинала не хочет сам делать пакеты, но нам это позарез нужно (а без пакетов нельзя, я однажды по ошибке /usr/lib снёс, когда удалял программу, установленную в обход пакетов, с тех пор в обход пакетов я никогда ничего не ставлю), мы соберём пакет сами, и поделимся им со всеми, а чтобы не было сомнений, что мы не добавили вредоносов, то будем это делать в виде pipeline на публичном CI, да ещё и по возможности reproducible. В смысле, что каждый может пойти на CI, взять контейнер докер оттуда, слить из него список пакетов, поставить такие же из репозиториев на свою машину, слить рецепт из репозитория, и построить. Но проблемв пришла от сервисов. Из нормальных CI я знаю только GitLab. В последнее время GitLab inс. слишком много себе позволяет, так что пришлось воздержаться от использования, гитхабовский CI имеет известные недостатки, другие - тоже. Платить за CI для свободного ПО для того, чтобы поделится пакетом ... ну я конечно понимаю, что бесплатного ничего не бывает, но платить за это я не готов. Если корпорация готова - то пусть она и платит, но не на неприемлимых условиях. Отсутствие нормального CI несколько обесценивает проект.

6. Это не единственный мой проект. У меня их дофига. Значительная часть моей деятельности в опенсорсе, к сожалению, сводится к исправлению недоделок в других проектах, которыми я вынужден пользоваться. Недоработок их оригинальных авторов. Это опенсорс и мне никто ничего не обязан, но всё же это отнимает время. Список моих проектов можно найти на GitHubе, но наиболее перспективны для внесения вклада в виде кода следующие проекты. File2Package - требуется дописать бэкэнды для остальных пакетных менеджеров (на самом деле не требуется, так как реально prebuilder работает только на apt, так как я сам сижу на Kubuntu). Автоматическое обновление метаданных я реализую потом, когда доделаю модуль для пробрасывания хуков в питон. UniGrammar - требуется реализовать механизм импорта модулей, он специфичен для каждого бэкенда, при этом всё должно быть совместимо с "бандлами", это большая работа, поэтому и не сделана. Также в планах лифтеры (aka frontend). Там есть прототипы лифтеров из регулярок и parglare, но нужно сделать лифтеры для каждого из бэкэндов (один из наиболее низко-весящих - antlr4, там есть api для получения ast) и отполировать всю машинерию до состояния, когда грамматики вообще не придётся руками постобрабатывать, для того, чтобы они транспилировались и работали. UniOpt - допилить метаоптимизатор. Я давненько не обучал модели, поэтому его пока не трогал. RDataParser - допилить конвертацию, формат я распарсил, обход дерева реализовал, но потом навалились другие проекты, так и осталось недоделанным (поэтому пришлось ограничится тестированием своих моделей на дейтасетах в нормальных форматах, в идеале нужно по как можно большему количеству дейтасетов проверить, но очень значительная часть из них - в R). Менее перспективны: AutoXGBoost - добавить LightGBM, запилить сборку CatBoost через нормальную систему сборки, и добавить CatBoost тоже. Но я это слишком давно не использовал, все мои последние модели были на TensorFlow.