Очень хорошо, конечно, что для C++ появились продвинутые системы управления зависимостями, вроде vcpkg и conan. Я сейчас без сарказма и иронии: в проекте для текущего заказчика используется vcpkg и это оказалось просто спасением, ибо заниматься поддержкой сборки FFMPEG/SDL на разных платформах это тот еще геморрой. А в vcpkg из коробки, берешь и пользуешься.
Плохо, однако, то, что этих самых систем не одна, а сразу несколько, vcpkg и conan только наиболее известные, наверное. Возможно еще и самые используемые. Но таки лучше бы, чтобы была всего одна такая система. Типа де-факто и де-юре стандарт.
Но у vcpkg и conan есть один фатальный недостаток, имхо, настоящая ахиллесова пята.
Обе эти системы централизованы в том смысле, что пакеты и версии пакетов в них появляются не просто так. В vcpkg нужно подготовить PR, который как-то проверяется, затем включается в основную ветку vcpkg. В conan, насколько я понимаю, аналогичная система (по крайней мере для попадания в conan.io/center).
При этом сроки принятия PR могут варьироваться в широких пределах. Например, мы зафиксировали SObjectizer v.5.8.0 еще 30-го июня. Тогда же были подготовлены и PR для vcpkg/conan. Но они так до сих пор не были приняты.
С одной стороны, подход vcpkg и conan можно понять: им хочется, чтобы включаемые туда версии были хоть как-то протестированы, чтобы была хоть какая-то гарантия того, что пакет (и конкретная его версия) компилируется.
Но, с другой стороны, представим себе, что в неком пакете обнаружилась критически важная проблема, эту проблему исправили, выкатили PR для vcpkg/conan и... И потом приходится ждать неделю(!!!), а то и больше, чтобы изменения были приняты.
И еще один момент: ну хорошо, пока там 1500 пакетов, тестирование и сборка на стороне vcpkg/conan может казаться оправданной (хотя там же не производится полного прогона всех тест-кейсов, которые есть в проекте). Но что будет, когда пакетов станет 3000? А когда 10000? В общем, мне кажется, что этот подход не масштабируется.
Так что я продолжаю придерживаться мнения, что C++ нужна единая система управления зависимостями (какой-то де-факто стандарт), но эта система должна быть либо вообще server-less (т.е. чтобы не было единого централизованного репозитория пакетов), либо этот репозиторий должен быть совсем минималистичным и внесение изменений в него должно быть простым и быстрым (по типу того, как это происходит в RubyGems).
На сколько правильно есть понимание (тут лучше ж_опытные поправят), для conan-a достаточно просто таскать сами рецепты пакетов, их собирать под таргет и использовать напрямую без использования централизованного хранилища.
ОтветитьУдалитьВ случае vcpkg есть overlay, и, соответственно, достаточно просто держать форк репозитория со своими версиями пакетов и методами сборки.
В общем случае serverless возможен, но тогда придётся каждому разработчику держать кэш собранных зависимостей и при фиксах каких-то пакетов их себе пересобирать.
@42
ОтветитьУдалитьЭто все можно делать. И, наверное, в больших проектах именно так и правильнее поступать: иметь собственный форк того же vcpkg (или vcpkg + набор overlays). Но тогда смысл централизованного vcpkg (или conan) теряется.
@NN
ОтветитьУдалитьЯ уже в предыдущем комментарии сказал, что если держать локальную копию vcpkg и патчить ее, то смысл в централизованном vcpkg сильно теряется.
Ссылки на блог-посты я даю в LinkedIn и VK, можно комментировать там. В FB я иногда захожу, но в основном в режиме read-only.
В conan это совсем не так.
ОтветитьУдалитьConan оперирует одноранговыми remote'ами -- репозиториями пакетов. conan.io в нем выделяется только тем, что обычно прописан в конфиге после установки.
Для того чтобы хостить свои репозитории, достаточно развернуть artifactory. На conan.io/downloads есть ссылка. Далее нужные репозитории прописываются в конфиге, а конфиг раскатывается по машинам, вручную или через conan config install .
Работает отлично.
У conan всегда есть локальный кеш пакетов, так что можно обходиться и вовсе без репозитория -- до какой то степени.
@Siborgium
ОтветитьУдалитьТак и в vcpkg есть возможность сделать свой форк основного репозитория vcpkg и, при необходимости, обновлять зависимости в нем самостоятельно. А потом, когда изменения доедут до апстрима, синхронизироваться. Можно даже и форк не делать, а создавать т.н. overlays.
Т.е., если у вас есть проект, который нуждается во внешних либах X, Y и Z, то можно иметь собственный vcpkg/conan и ставить X, Y, Z через него.
Я сейчас с точки зрения разработичика библиотеки говорю. Насколько оперативно разработчик может выкатить очередной релиз и насколько быстро он станет доступным для тех пользователей, которые не заморочились собственным vcpkg/conan.
PS. Это вы на LOR-е под ником Siborgium участвуете?
@Siborgium
ОтветитьУдалить> Насколько я понимаю, оверлеи vcpkg это сугубо локальное явление?
Да. Насколько я понял, это механизм подменить пакет из vcpkg на другой локально на своей машине. Но vcpkg меняется со временем, наверняка я уже чего-то не знаю.
> Это вы, как разработчик библиотеки, озадачиваетесь своим conan.
А вот этого как раз и не хочется. Да и непонятен смысл conan-center тогда, если разработчики библиотек начнут озадачиваться своими копиями conan-а.
> >PS. Это вы на LOR-е под ником Siborgium участвуете?
> Да.
О, неожиданно. Приятно вас здесь видеть.