LINUX.ORG.RU

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

 ,


2

2

Выпущен первый релиз WiX.Py, кроссплатформенного сборщика MSI инсталляторов. Основное назначение - предоставить проектам кроссплатформенных приложений возможность собирать MSI пакеты без использования выделенного сервера на базе Windows и проводить сборку на Docker-контейнерах. Это позволяет сэкономить на инфраструктуре проекта и ускорить Continuous Integration сборки. Вместе с тем, WiX.Py работает и на Windows.

В отличии от WiX (стандарт в области сборки MSI), WiX.Py не требует гигантских сборочных XML файлов и сильно упрощает подготовку MSI-инсталляторов для средних и мелких проектов.

WiX.Py - консольное приложение, использующее на Linux библиотеку libmsi, а на Windows стандартную msi.dll для генерации MSI пакетов. Поэтому в отличии от множества оберток для WiX (python-wix, go-msi, electron-wix-msi и т.п.), WiX.Py самодостаточное приложение. Поскольку WiX.Py написан на python, его можно использовать как питоновский пакет в сборочных скриптах и при необходимости самостоятельно расширять функционал.

>>> Подробности

★★★★★

Проверено: tailgunner ()

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

atsym ★★★★★ ()
Ответ на: комментарий от atsym

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

Linfan ★★★★★ ()
Ответ на: комментарий от atsym

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

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

Linfan ★★★★★ ()

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

Linfan ★★★★★ ()

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

Aceler ★★★★★ ()
Ответ на: комментарий от Aceler

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

actionless ★★★★★ ()
Ответ на: комментарий от actionless

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

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

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

actionless ★★★★★ ()
Ответ на: комментарий от actionless

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от Linfan

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от hobbit

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от hobbit

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Linfan

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

anonymous ()
Ответ на: комментарий от anonymous

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

mx__ ★★★★★ ()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

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

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

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от mx__

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

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

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

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

mx__ ★★★★★ ()
Ответ на: комментарий от Linfan

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

h4tr3d ★★★★★ ()
Ответ на: комментарий от h4tr3d

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

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

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

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

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

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

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

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

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

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

h4tr3d ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.