Реалии open‑source разработки на примере Conan и userver

[eao197]

Статья затрагивает сразу несколько важных аспектов и OpenSource здесь только один из. Возможно даже не самый важный.

Позволю себе заострить внимание вот на каком моменте: имхо, системы управления зависимостями для C++ не должны быть централизованными (как это происходит с Conan и vcpkg). Вместо того, чтобы сделать рецепт для условной библиотеки X (которая зависит от Y и Z) и отправить PR на включение этого рецепта в Conan/vcpkg, было бы лучше опубликовать этот рецепт где-то отдельно. Например, в репозитории библиотеки X.

В рецепте для X были бы ссылки на аналогичные рецепты для Y и Z, что-то вроде (синтаксис условный):

"depends": [
  {"name": "Y", "receipe": "https://github.com/y-lib-org/receipes/v1.2.3"},
  {"name": "Z", "receipe": "https://github.com/z-lib-org/receipes/v3.2.1"}
],
...

В проекте, где потребовался бы X, было бы что-то вроде:

"depends": [
  {"name": "X", "receipe": "https://github.com/x-lib-org/receipes/v0.1.1"},
],
...

При загрузке зависимостей сперва бы сходили в репозиторий X, достали бы оттуда рецепт. Потом сходили бы по репозиториям, которые описаны в рецепте X, достали бы оттуда информацию и т.д.

При такой распределенной структуре можно было бы не зависеть от того, что в условный conan-center PR могут принимать неделями. Да и для каких-то библиотек можно собственные рецепты писать и поддерживать (даже если авторы библиотек не хотят потом эти рецепты к себе в апстрим забирать).

[ReadOnlySadUser]

Но... Conan так умеет. А если чего-то не умеет, он довольно легко расширяется (ибо питончик).

Рецепты хранятся вместе с кодом, registry можно зеркалировать и поднимать свои

[eao197]

Рецепты хранятся вместе с кодом, registry можно зеркалировать и поднимать свои

Это хорошо для внутрикорпоративных разработок. Сделал зеркало и бодаешься с ним сам потом.

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

[ReadOnlySadUser]

Выбор-то небольшой) Мы или пилим централизованно и одинаково, или оставляем всё как было)

Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)

[eao197]

Мы или пилим централизованно и одинаково

О том, к чему это ведет, видно из статьи.

Сам я на Conan давно забил, делаю обновления только на vcpkg. Но и там были случаи, когда принятия PR нужно было ждать неделями.

или оставляем всё как было

Не понимаю такой двоичной логики. Есть еще вариант – комитет таки перестает вредить (шутка) и рожает наконец стандартное описание зависимостей. Тогда все будут описывать зависимости проектов в стандартом виде. Просто не обязательно собирать готовые рецепты в одном месте (как это сейчас происходит с Conan и vcpkg).

Помнится, какой-то подкомитет посвященный тулингу в комитете по стандартизации C++ есть. Результатов пока не видно. Но он есть.

[ReadOnlySadUser]

Если их не собирать в одном месте, то и гарантий собираемости не обеспечить. А если не обеспечить, то и зачем оно тогда нужно, просто банально проще идти старым путём

[eao197]

Если их не собирать в одном месте, то и гарантий собираемости не обеспечить.

Это слишком сильное и, полагаю, бездоказательное утверждение.

[ReadOnlySadUser]

Что бездоказательного в том, что доверяя владение другому лицу, ты больше ничего не можешь гарантировать? Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать

[eao197]

Что бездоказательного

Чуть меньше чем все.

что доверяя владение другому лицу, ты больше ничего не можешь гарантировать?

Как будто отправляя рецепт в Conan или в vcpkg вы поступаете как-то иначе.

Внешние ссылки склонны умирать, устаревать и просто бесследно исчезать

Что в рецепте Conan-а, что в порте vcpkg лежат точно такие же внешние ссылки, которые склонны умирать, устаревать и просто бесследно исчезать ©

PS. Предлагаю воздержаться от продолжения этого бесполезного обсуждения ваших глупостей.

[Xadok]

Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)

Это тема следующей статьи, и почему так делать не нужно. Пока аргументы готовлю

[ReadOnlySadUser]

Я знаю, почему так делать не надо) Так уж вышло, что я и сам немало времени провел в работе над этими бедами с зависимостями, я бы может и написал даже об этом статью, если бы она не сводилась к тому, что собственные велосипеды неизбежны, а чужие велосипеды вам не подойдут и зря вы читали эту статью)

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

[DungeonLords]

Жаль The Qt Group прекратили официальную поддержку Conan… Чем больше организаций пользуются технологией, тем лучше для всех.

[Verona90210]

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

[Xadok]

Вы либо используете пакетник и тянете все зависимости через него. Либо страдаете. Qt срезали косты и переложили ответственность на пользователей, чтобы это была их проблема.

[Verona90210]

Мазохистом надо быть чтобы тянуть Autotools в Конан... За упорство респект конечно, но обычно на таких задачах люди и выгорают в ноль

[Playa]

Как только userver выложили в опенсорс было желание написать под него порт для vcpkg, но на тот момент сложилось впечатление, что система сборки была написана под внутреннюю кухню - одна платформа, вроде бы некоторые зависимости нужно было выкорчёвывать, install step не описан (могу ошибаться). Надо как-нибудь на досуге попробовать совершить второй заход. С добавлением/обновлением портов в vcpkg опыт положительный.

[Ryppka]

Я, конечно, ничего в теме не понимаю, но, например, buildroot с этими проблемами справляется, не?