Возможно, мне стоит сделать на примере какого-то одного проекта сравнение того как будет выглядеть конфиг для makefile и для runo для разных типов проектов (Rust/Python/Go/...)
Сравнение с just гораздо более оправдано. Как видите, они оба существуют, just-ом пользуется довольно много людей, хотя есть мейкфайл. runo это шаг в ту же сторону, но ещё чуть дальше - более простой и популярный формат конфига, который (я надеюсь) позволит быстрее настроить всё что нужно и забыть об этой части; отсутствие необходимости установки. Возможно, мне стоит на примере какого-то одного проекта попытаться показать как это будет выглядеть для makefile, just и runo, чтобы сравнение было более наглядным.
Всё верно. В аналогии с автомобилем - на заводе ассистент всё-таки должны 1 раз настроить, чтобы он знал что конкретно нужно делать когда его просят "поехали домой". Так же работает и runo - достаточно один раз написать в конфиге что конкретно для данного репозитория означает test/build/... и дальше можно забыть об этом, ассистент будет брать эту информацию из конфига
Совершенно верно, но кажется именно так выглядит эволюция :) время идёт, сценарии использования меняются, приходится адаптироваться. Вечны только Linux и Git :)
Я бы говорил не о преимуществах, а скорее о фундаментальных различиях между Makefile и runo, потому что они решают разные задачи.
Makefile был разработан задолго до появления Docker и главной его задачей было оптимизировать процесс компиляции больших проектов. runo не претендует на это. Своей основной задачей runo ставит упрощение работы с репозиториями и запуск любого действия одной простой командой, без предварительной установки, или настройки чего бы то ни было и для этого runo полагается на docker/compose.
Например, если у вас есть проект с Makefile, который должен билдится например на Debiad, вы не можете просто взять и запустить `make build" на вашей системе, если она не содержит всего, что нужно для этого таргета. Вам вероятно придётся оборачивать всё в докер и выполнять что-то вроде "docker run ... make build"
А runo можно настроить так, чтобы можно было запустить просто "./runo build". Под капотом там вполне может быть и make (мы используем такую связку в тех проектах, котрые полагаются на make для компиляции). В Rust репозиториях вместо make скорее всего будет cargo, в Python - uv, или что-то похожее. Но с помощью runo можно будет в любом из этих репозиторив запустить просто "./runo build"
Т.е. runo это более высокоуровневая абстракция, надстройка над Makefile, cargo, uv (для сценария с билдами), которая призвана упростить жизнь в усложняющемся мире, где появляется всё больше языков и технологий и где одному и тому же человеку приходиться взаимодействовать с несколькими разными проектами, которые используют разные стеки технологий.
Надеюсь, что вторая часть статьи сможет более детально осветить эти моменты.
Возможно, мне стоит сделать на примере какого-то одного проекта сравнение того как будет выглядеть конфиг для makefile и для runo для разных типов проектов (Rust/Python/Go/...)
Сравнение с
justгораздо более оправдано. Как видите, они оба существуют, just-ом пользуется довольно много людей, хотя есть мейкфайл.runoэто шаг в ту же сторону, но ещё чуть дальше - более простой и популярный формат конфига, который (я надеюсь) позволит быстрее настроить всё что нужно и забыть об этой части; отсутствие необходимости установки. Возможно, мне стоит на примере какого-то одного проекта попытаться показать как это будет выглядеть дляmakefile,justиruno, чтобы сравнение было более наглядным.Всё верно. В аналогии с автомобилем - на заводе ассистент всё-таки должны 1 раз настроить, чтобы он знал что конкретно нужно делать когда его просят "поехали домой". Так же работает и runo - достаточно один раз написать в конфиге что конкретно для данного репозитория означает test/build/... и дальше можно забыть об этом, ассистент будет брать эту информацию из конфига
Совершенно верно, но кажется именно так выглядит эволюция :) время идёт, сценарии использования меняются, приходится адаптироваться. Вечны только Linux и Git :)
Я бы говорил не о преимуществах, а скорее о фундаментальных различиях между
Makefileиruno, потому что они решают разные задачи.Makefileбыл разработан задолго до появленияDockerи главной его задачей было оптимизировать процесс компиляции больших проектов.runoне претендует на это.Своей основной задачей
runoставит упрощение работы с репозиториями и запуск любого действия одной простой командой, без предварительной установки, или настройки чего бы то ни было и для этогоrunoполагается на docker/compose.Например, если у вас есть проект с
Makefile, который должен билдится например на Debiad, вы не можете просто взять и запустить `make build" на вашей системе, если она не содержит всего, что нужно для этого таргета.Вам вероятно придётся оборачивать всё в докер и выполнять что-то вроде "docker run ... make build"
А runo можно настроить так, чтобы можно было запустить просто "./runo build". Под капотом там вполне может быть и make (мы используем такую связку в тех проектах, котрые полагаются на make для компиляции). В Rust репозиториях вместо make скорее всего будет
cargo, в Python -uv, или что-то похожее. Но с помощьюrunoможно будет в любом из этих репозиторив запустить просто "./runo build"Т.е.
runoэто более высокоуровневая абстракция, надстройка надMakefile,cargo,uv(для сценария с билдами), которая призвана упростить жизнь в усложняющемся мире, где появляется всё больше языков и технологий и где одному и тому же человеку приходиться взаимодействовать с несколькими разными проектами, которые используют разные стеки технологий.Надеюсь, что вторая часть статьи сможет более детально осветить эти моменты.