WiX.Py 0.1 - кроссплатформенный сборщик MSI пакетов

Сегодня пятница, а это значит — пора делать новые ночнушки для sK1 2.0! ;-)

слух, ну только закончили релиз готовить - имей совесть:)

только закончили релиз готовить

AP, а я тебе говорил что релиз будет в этом году! ;-P
>>> http://libregraphicsworld.org/blog/entry/2018-in-perspective

А ты мне не верил...

Neither of them is certain, unfortunately.

Ты путаешь проекты. Подготовили релиз WiX.Py, а не sK1 2.0

WiX.Py нужен для виндовых версий sK1 2.0/UC 2.0

А причем тут докер-контейнеры ?

Очень просто - чтобы собрать MSI в докере (современные CI построены на контейнерах), MSI сборщик не должен зависить от иксов,вайна. Вот и делался инструмент под эти критерии.

Т.е. можно одной рукой запустить сборку deb, другой rpm, третьей рукой запустить сборку Flatpak, snap и ещё останется возможность запустить сборку MSI и всё в одном контейнере?

да, в sK1 Project так и делаем - все теперь собираем в докере одним заходом, сразу аккуратно сортируя по полочкам: https://sk1project.net/viewpage.php?page_id=24

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

но они все запускаются с одного линуксового хоста

правильно отмечено. Но с небольшой поправкой: это может быть как локальный хост, так и линуксовый инстанс в клауде (AWS, GCE, Azure и т.п.). В идеале сборка запускается либо по триггеру из git, либо по крону, либо по команде. Собирает и выкладывает на доступный в сети ресурс результаты сборки в автоматическом режиме или с минимальным участием девопса.

Ну с wine понятно, а как может быть сборщик msi зависеть от xorg ? непонятно. И вообще есть ощущение что в новости название докер упомянули для красного словца, так типа модно :)

И вообще есть ощущение что в новости название докер упомянули для красного словца, так типа модно

А вот и зря. Намучались со сборкой MSI более чем. Все остальные пакеты собирали в докере, даже portable-версию для винды. А MSI требовал не просто винду, а еще и с запущенным десктопом - VirtualBox в headless режиме просто тупо зависал. И при этом собирался каждый вариант (32/64bit) по пол-часа! Это ж никаких нервических сил терпеть не хватит :) Попытки запустить wine в докере выяснили, что вайн прибит гвоздями к иксам. Народ монструозил что-то похожее в докере, но это все нестабильно работающее и диких размеров на гигабайты.

А теперь с WiX.Py сборка MSI не сложнее упаковки в zip. И по времени примерно столько же занимает.

Чисто в качестве пруфа:

https://hub.docker.com/r/sk1project/

Один из имиджей - msw-packager. Вот на нем и живет сборка MSI.

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

Для девопсов это маркер - никто не будет изучать и долго ковыряться с тулзами. Проще сразу сделать акцент на докере.

да никто и не говорил про локальный

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

у меня как раз есть пара задач

Если какого-либо функционала будет нехватать - пишите. Добавить фичи и выкатить еще один релиз несложно.

MSI-то хорошо. Но сначала надо сами бинарники сделать. Как я понимаю, часть sK1 написана на Си. Как вы виндовые сборки под линуксом делаете - линуксовым MinGW или ещё как-то?

В нашем проекте «мутабельная» часть кода на python. Бинарная часть меняется крайне редко, поэтому она закеширована внутри докеровского имиджа. Если происходят изменения в бинарной части - пересобираем кеш и обновляем докеровский имидж. А 99% сборок этого не требуют.

Проекты, основанные на С/С++, могут делать кросскомпиляцию на Mingw.

Понятно, спасибо. Значит, это просто не мой случай.

Если у вас обязательна сборка на MSVC, вы можете собрать MSI на винде, используя сабж - всяко проще, чем писать XML-портянки для WiX :)

Не-а, меня MinGW вполне устраивает.

Другое дело, что я хочу свести к минимуму захламление хост-системы — не только самим MinGW под чужую архитектуру, но и собранными под него библиотеками. Я уже задумался, не применить ли для этого ReactOS в виртуалбоксе (благо виртуалбокс у меня всё равно уже есть) — но возможно, действительно, имеет смысл посмотреть в сторону докера...

В любом случае Ваш проект интересен. Я сейчас для своих виндосборок применяю Inno Setup под виндой. Он просто конфигурируется и умеет запускаться в пакетном режиме, но делает не MSI, а традиционный SETUP.EXE, что в 2018 году уже не так интересно...

Я уже задумался, не применить ли для этого ReactOS в виртуалбоксе

Докер гораздо легковеснее - ведь вам для сборки нужно только файловое окружение, а не полноценно работающая система. Тем более, что виртуалбокс порой ведет себя капризно. И кстати, сборка имиджей докера весьма простая задача. Главное начать, а потом на виртуалбокс уже никакими калачами не заманишь :)

под виндами городить обратный порт линуксовой разработки??? Чтобы убедиться, что питон умеет парсить xml? я бы потратил день-неделю-месяц (в зависимости от проекта) и разобрался с Wix-ом. Повторить все фичи Wix-а - это задача для энтузиастов (учитывая, что нетривиальные задачи там через XSLT идут).

мсье, вы таки даже сабж не читали, но уже осуждаете ))) WiX.Py не повторяет WiX в плане парсинга xml. Более того, он эти xml не использует от слова совсем. Модель WXS документа строится в процессе сборки MSI но ради утилитарных нужд. А на уровне msi.dll/libmsi у обоих продуктов одинаковые возможности, потому как там функционал на пальцах пересчитать можно.

я бы потратил день-неделю-месяц (в зависимости от проекта) и разобрался с Wix-ом

...и еще не забудьте освоить остальное всякое разное по Винде :) WiX низкоуровневый, и он напр. предоставляет возможность записи в регистри, но выполнить ассоциацию типов файлов со своей аппликухой через регистри вы должны сами. Поэтому «пилите Шура гири - они золотые» :)

да не читал, простите.

не очень понял, что значит на уровне msi?

ваша тулза умеет харвестить все что есть в дереве директории? на каком уровне xls функциональность у вас работает?

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

Пусть наши гении поработают немного, чтобы их тулза стала хотя бы на 1/100 такой же стабильной, как Wix )))

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

но если говорить о приложении средних размеров с сотнями установочных файлов, интеграцией с приложением, всякими докачками, апдейтами и тд., это врядли заменит Wix... (или вининстолер, для которого викс - тоненькая оболочка) Мне кажется, что Wix выбирают, потому что это очень близко к родному API...

Аппликуха делалась для инсталлеров sK1/Uniconvertor (около тысячи установочных файлов). Интеграция с эксплорером есть, регистрация в системе тоже. В целом достаточно для софтин класса Inkscape, Gimp и т.п.

Заменить WiX софтинка может на уровне малых и средних проектов, в которых некому возится с инсталлерами. Для энтерпрайза есть WiX - коммерсы способны оплатить труд профессионала по инсталлеру. И опять же это не замена msiexec - это сборщик пакетов для него. АПИ тут не причем - внутрях MSI тривиальная SQL база с таблицами и CAB файл. Что в базу запишешь, то и будет.

ваша тулза умеет харвестить все что есть в дереве директории?

ессно - все собирается рекурсивно. И никаких километровых xml. Ваще никаких xml :)

Пусть наши гении поработают немного, чтобы их тулза стала хотя бы на 1/100 такой же стабильной, как Wix )))

Тулза более чем стабильна уже. Она делалась на основе гномовских msitools и вполне можно было ставить версию 1.0

не очень понял, что значит на уровне msi?

На уровне библиотеки msi.dll - она под капотом и у WiX и у WiX.Py.

простой вопрос:

вот есть маленькое приложение, куча dllек, всяких других файликов разного типа, например Qt-шный рантайм (с qml-ной пургой, пока далекой от стабильности), файлы с данными для апликухи, которых много и которые всегда разные, дерево документации, которую генерит статический генератор, тоже постоянно изменчивое (сегодня один генератор, завтра - другой).

Может ли ваша тулза пройти по дистрибутиву и распихать все что надо в нужные места сама?

Фактически, это и должен делать XSL ный движок, он вроде работает, но лишний раз возиться с этим нет желания...

простой ответ:

Ваш проект наверняка имеет сборочные скрипты аля automake/cmake. Формирование инсталляционного фолдера - это их задача. Для WiX.py положите все в один фолдер и его софтина отпроцессит.

не, скриптов нет - в Вижуал студио собирается. я наваял этот самый xsl, который руками вставляю в проект. Потом приходится проект немного править, такой вот косяк... Было бы удобно решать какие то задачи через Wix, а не при первом запуске приложения, но похоже - это для меня рокет-сайнс...)))

WiX.Py на основе Unix-way - только сборка MSI. Это не система сборки проектов. Это только билдер MSI пакетов. И основное применение - на Linux собирать инсталлеры кросплатформенных софтин. А сборочные скрипты у софтинок всегда уже есть.

в Вижуал студио собирается

Автоматизация сборки должна быть. Без этого не будет ни CI ни CD.

да, я не иду по Unix-way.

Полностью на cmake переходить - это большой объем работы для меня.

Хотелось бы, чтобы среда все подхватила и собрала.

Так как в Андроид Студио или в QtCreator (в отдаленной перспективе) ;))).

Ну сабж точно не комбайн для таких операций :)

Кстати вспомнил тут. Специально для контейнеров МС запилила в нативе NET и power-shell, а что разве на этих штуках нельзя msi рулить ?

MSI это по сути SQL база + CAB-файл. Т.е. это просто набор данных. Рулить можно на чем угодно. Касательно контейнеров - на винде свой докер. Но к никсовому он никак не относится. А смысл работать на никсах в докере, чтобы не усложнять сборочную цепочку.

Что такое MSI я давно знаю. Я не очень понимаю, я что то не понятно написал ? Повторяю : на NET и/или power-shell нельзя манипулировать MSI ? И причем тут windows-контейнеры ? То что они отличные от linux-контейнеров я тоже давно знаю.

Типа : https://github.com/oleg-shilo/wixsharp

на дотнете - можно. Есть же Wix# пакет. В разрезе:

Специально для контейнеров МС запилила в нативе NET

в виндячем докере можно манипулировать. Или я неправильно понял мысль?

Кстати, на VB и JS тоже можно - есть такой пакет MakeMsi, написанный на скриптах. Тоже генерит MSI, хотя и призвездено.

Причем тут виндячий докер ?

МС специально выпустила нативные (для линуха) АСП_НЕТ, ДОТ-НЕТ, ПОВЕР-ШЕЛЛ, МССКУЛЬ и там еще что то, чтобы гонять в линух-контейнерах свои поделки на АСП.

ааа... понял :) Не, не взлетит. Все эти инструменты по работе с MSI используют msi.dll - сомневаюсь, что все системные виндовые либы порты ASP, powershell тащат с собой.

Не, не взлетит. Все эти инструменты по работе с MSI используют msi.dll

Спасибо понятно. Я же хз если внутри ДОТ-НЕТ такая либа или нет.

А как подписываете?

У меня докер и mxe для подобного.

Слушай, а custom actions особенно из dll, особенно Type 17, умеете?

custom actions особенно из dll, особенно Type 17, умеете?

custom actions сейчас добавляем. Будет в следующем релизе. Из чего - пофиг, вызов MSIEXEC делает, а исполняемый скрипт/бинарь подшивается любой.

А как подписываете?

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

Из чего - пофиг

Type 1 - должен записаться в виде битсрима в таблицу Binary, насколько понимаю, в сам MSI, тогда как Type 17 может быть в CAB файле и иметь ссылку в таблице Files. Ещё CA могут быть Immediate и Deferred. И управлять очередностью запуска: иногда нужно попросить MSI сделать перезагрузку по окончании установки... Достучаться до API, который это может сделать - только из Immediate CA.

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

Да я больше спросить хотел КАК это делается. Я подписываю драйвер при помощи SignTool.exe из комплекта виндового SDK - подписывается. Потом подписываю так же msi... хрен! Процесс завершается без ошибки, в свойствах файла информации о подписи не появляется, при запуске msi - Unknown publisher. С учётом того, что винда для меня чужая система... меня это в уныние повергает.

А сертификат у меня сейчас только в виде USB донгла, воткнутого в билд-сервер в Канаде :)