Реализация скрипта-перехватчика сборки #81
Conversation
nixel2007
force-pushed
the
feature/build-scripts
branch
from
fe0f96d to
206049f
Compare
artbear
left a comment
artbear
left a comment
There was a problem hiding this comment.
Хорошая работа.
Предлагаю сделать небольшие исправления.
src/Классы/СборщикПакета.os
Outdated
There was a problem hiding this comment.
На этапе после сборки также было бы удобно иметь доступ к АрхивПакета.
Предлагаю добавить.
src/Классы/СборщикПакета.os
Outdated
There was a problem hiding this comment.
Предлагаю методы ВызватьСобытиеПриСборке и ВызватьСобытиеПослеСборки вставить сразу после метода ВызватьСобытиеПередСборкой, чтобы не разрывать текст и похожие блоки кода.
|
@pumbaEO @EvilBeaver Нас с Никитой все устраивает, код-ревью и проверки сделали. |
|
У меня есть замечание. В opm уже предусмотрен клиентский кастомизирущий скрипт. Данный PR делает второй "спецфайл", но для этапа сборки по образу и подобию первого. Однако, для разработчика уже есть клиентский кастомизирующий скрипт. Это, внезапно, packagedef. Я помню дискуссию о том "код" это или все-таки "конфиг". Когда я задумывал opm и воровал packagedef с Ruby, я своровал оттуда и идею кодоконфига. По задумке - "перехватчик сборки" это и есть packagedef. В принципе, если есть конкретные аргументы, почему это должен быть отдельный файл, я буду рад их услышать и принять. Как вариант, можно было бы добавить в файл |
EvilBeaver
left a comment
EvilBeaver
left a comment
There was a problem hiding this comment.
Есть некоторый идейный вопрос
|
@EvilBeaver основная проблема использования packagedef - он зачитывается при различных операциях внутри opm - установки по зависимостям описания пакета, установки самого пакета, сборки и прочих. Это приводит к тому, что для vrunner, например, шаг сборки обработок (который добавлялся в packageDef для команды build) начал выполняться и при обычном Вероятно частично могло бы помочь пробрасывание текущего режима (install/build/etc...) в контекст описания пакета, но и усложнения того же packagedef это бы добавило. Предлагаемая реализация, имхо, наиболее компромисная со строгим разделением логики и ответственности между файлами. |
|
При opm install он зачитывается для генерации xml которую съедает потом vsc? |
|
Нет, из него зачитываются зависимости пакета и вызывается рекурсивное их разрешение/установка. |
|
Ну окай, я так-то не против. |
|
А мне нравится возвращение к идее кодоконфига. Может быть, прямо в packadef и определять спец.методы обработчики событий, аналогично build.os и install.os ? Это вроде бы несложно сотворить. |
Link: vanessa-opensource/vanessa-runner#135