Cross Platform Package Manager for C++

Интересны фидбеки, стоит ли мне продолжать?

Уже есть такие проекты, как:

1. Conan
2. Hunter
3. Buckaroo

Чем твой лучше/хуже? Судя по их распространённости, это не прижилось в мире C++. Возможно если packages попадут в стандарт что-либо изменится. Но пока – увы.

Наверное по количеству пакетов всех сейчас заруливает vcpkg. Но у него пока нет поддержки версионности.

Что это за ненужно на баше?

CMake-only решения не нужны. Или его можно держать только для пакетизации отдельно не засоряя саму репу?

В вашем README нет нормального описания того, по какому принципу работает ваш инструмент. А так же нет нормального описания того, что нужно сделать пользователю, чтобы:

* с помощью вашего инструмента взять для своего приложения чужие зависимости;

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

Собственно, если есть желание продвигать то, что вы сделали, то README нужно расширить. Либо вставить в него хорошо заметные ссылки на соответствующие описания.

vcpkg

Он разве кросс-платформенный?

Он разве кросс-платформенный?

да, даже на FreeBSD работает...

Я не знал, думал Win-only.

FreeBSD 13 дней назад коммит приняли, просто на глаза попалось :)

https://github.com/Microsoft/vcpkg/pull/4917

Да. И в освоении простой.

Но у него две большие проблемы. Первая, как уже было сказано: это отсутствие версионности.

Вторая — это то, что ты не можешь сам опубликовать свежую версию своего пакета. Нужно делать PR и ждать, пока PR примут. В большинстве случаев принимают в течении суток, но бывают и задержки в несколько дней.

Тогда как в том же conan-е ты сам можешь публиковать пакеты когда захочешь.

если порыться в сети, то их наверняка найдётся не один десяток. ни один не прижился, ибо программистам это не нужно. в дистрибах это тоже не нужно. поэтому и существует оно только формально.

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

и никому не нужна версия библиотеки

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

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

В каждом отдельном приложении зачастую проще иметь индивидуальную копию набора библиотек «паралельно» к основной операционной системи, что-б избежать dependency hell.

В случае embedded систем,их тоже нужно где-то в чём-то собирать и тестировать, и хорошо иметь отдельную конфигурацию библиотек отличную от основной операционной системы.

угу. и тогда зачем все эти дистрибутивы? файлопомойка здесь и сейчас. кушали уже в маздае. спасибо, не надо.

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

- Как вы делаете CI? - Вы можете на чистой инсталляции ОС кросс-платформенным образом собрать приложение из исходников одной командой?

chroot это не кросс-платформенный подход, верно?

https://github.com/Microsoft/vcpkg/commit/6d5bf1b2006c50194c768667f86b8915243... Да, таки добавили поддержку Linux, MacOs и прочее в Апреле 2018

pak-c-mak пакет это bash скрипт, который может выполнить любые нужные инструкции, в том числе и cmake.

Спасибо всем за комментарии, есть над чем поработать, немного самаризирую:

1) Добавить сравнительный анализ с Conan, hunter и vcpkg

2) написать более подробные инструкции

3) добавить поддержку версиям

Основное преймущество: это модель распределённых репозиториев - каждый паблишер библиотек может иметь свой репозиторий со своими пакетами и кросс-платформеность.

- Как вы делаете CI?

К слову, CI элементарно делается в связке с докером (пожалуй, единственное его оправданное применение). Поднимается образ целевой системы, происходит сборка, прогон тестов, опакечивание. Потом пакет забирается, а образ грохается. В итоге, в системе нет лишних версий библиотек

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

А еще лучше на самом Си++, какой-нибудь гарантированно кросплатформенный код без зависимостей от всего (чтобы зависил только от std ++ либы) и ровно в одном файле, без хедеров, просто в package_manager.cpp - тогда будет вообще красота, т.к. пользователю менеджера пакетов не нужно будет кроме Си++ ничего тянуть типа Питона и Баша - а просто скачать файл, собрать его и всё.

И вот кстати как раз в винде такая штука пользовалась бы большей поппулярностью - например в Линуксе - что может быть проще подключить буст к проекту, поставил средствами дистрибутива и линкуешься к нему. А в винде это как-то руками нужно делать, потом пути прописывать и т.п.

Я думаю ЦА этих мнженеджеров не надо ничего куда-то там публиковать. А так и Тоти то умеет интегрироваться с artifactory и никаких prов слать не нужно.

Ага и build reproducibility разработчикам тоже не нужно. Okay.jpg

У Conan тоже косяков хватает Из тех на что в команде напарывались между версиями они иногда ломают сортировку exportных файлов, а т.к они пакуют все в tar то жозаливать новые пакеты к этому рецепту может только ~такая же версия

Я думаю ЦА этих мнженеджеров

ЦА аудитория этих менеджеров такая же, как и ЦА пользователей Cargo, Maven, Cabal, RubyGems и кучи других менеджеров зависимостей, которые являются де-факто (а то и де-юре) стандартными средствами управления зависимостей для нормально развивающихся языков.

И нужно быть просто конченными дурами, чтобы утверждать, что менеджеры зависимостей в C++ никому не нужны.

Продолжать не стоит. Лучше присоединиться к существующим менеджерам пакетов. https://build2.org/, например. Собирается из исходников или можно поставить бинарные пакеты https://build2.org/install.xhtml (в самом низу есть ссылка на неофициальные пакеты).

Основное преймущество: это модель распределённых репозиториев

В build2 ты можешь указать свой git репозиторий.

Maven

Увы, в жабка-мирке нет порядка, нет единой тулзы как в Rust.

Там просто что-то специфичное для cmake есть и оно заявлено обязательной зависимостью, вот я и подумал. Тогда можно будет попробовать как-нибудь.

Вторая — это то, что ты не можешь сам опубликовать свежую версию своего пакета. Нужно делать PR и ждать, пока PR примут. В большинстве случаев принимают в течении суток, но бывают и задержки в несколько дней.

Он централизованный? Т.е. все пользуются одним глобальным репозиторием, в котором указаны все существующие во Вселенной пакеты?

Он централизованный?

Да.

А можно сделать свой форк, и использовать его для своих целей, или vcpkg завязан именно на один центральный репозиторий, контролируемый MS?

И еще вопрос - а есть какие-то планы, чтобы vcpkg мог хранить более одной версии одного и того же пакета, или это всегда будет делегироваться git?

А можно сделать свой форк, и использовать его для своих целей

Можно. Ты делаешь клон vcpkg, а потом делаешь то, что хочешь.

И еще вопрос - а есть какие-то планы

Понятия не имею. О vcpkg знаю поскольку приходится поддерживать пакет для vcpkg.

vcpkg делает Microsoft. А с ним лучше не связываться. Тебе же дороже обойдётся. У них там херня типа, как добавить библиотеку в msbuild, или как заюзать CMake через Open File диалог.

Учитывая то, что Conan и Hunter разрабатывались с прицелом на OSS инструментарий, но работают под винды без проблем, я бы отдал предпочтение именно им. Я использовал оба, вникнуть в них не представляет сложности.

vcpkg делает Microsoft. А с ним лучше не связываться. Тебе же дороже обойдётся.

Это вы сейчас github, походу, закопали. Его же уже делает Microsoft.

Учитывая то, что Conan и Hunter разрабатывались с прицелом на OSS инструментарий, но работают под винды без проблем, я бы отдал предпочтение именно им.

Вроде как и vcpkg работает без Windows без проблем.

Conan делают люди на зарплате у JFrog. И их задача в том, чтобы приводить клиентов к JFrog-овским сервисам. Поэтому не случайно то, что Conan делают те же чайники, что делали biicode, на котором эти чайники сперва хотели зарабатывать.

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

При этом если vcpkg нормально переваривает проекты с CMake-овскими myprj-config.cmake и при использовании зависимостей через vcpkg ты пишешь в нормальном виде:

find_package(myprj)
...
target_link_libraries(some_target myprj::deptarget)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
...
target_link_libraries(some_target ${CONAN_LIBS})

Conan делают люди на зарплате у JFrog. И их задача в том, чтобы приводить клиентов к JFrog-овским сервисам. Поэтому не случайно то, что Conan делают те же чайники, что делали biicode, на котором эти чайники сперва хотели зарабатывать.

А если поменять Conan -> vcpkg и JFrog -> MS, что-то поменяется?

Conan пишут не только люди из JFrog, но и много энтузиастов. Общаясь с одним таким, я, таки, понял, что менеджер пакетов дистрибутива и пакетный менеджер для C++ настолько для разного сделаны, что почти не пересекаются (даже если проект делается только для Ubuntu, например, и в результате все равно делаются deb пакеты).

P.S. IMHO, Conan обречен, так же как и biicode (только в отличие от biicode в Conan влили гораздо больше бабла, потому он еще шевелится). Conan - это только первый шаг к созданию менеджера пакетов для C++. Второй шаг он не переживет.

Conan - это только первый шаг к созданию менеджера пакетов для C++. Второй шаг он не переживет.

А что является вторым шагом?

А что является вторым шагом?

Создание пакетного менеджера совмещенного с системой сборки.

Менеджер должен быть удобным, простым (как и система сборки) и они должны быть очень тесно связаны (система сборки должна знать с какими зависимостями линковать проект, эта же информация нужна пакетному менеджеру, чтобы разрешить зависимости - получается дублирование, лучше если будет общий конфиг или набор конфигов, которым умеют пользоваться все инструменты). Вряд ли получится сделать пакетный менеджер, который стыкуется с CMake, Autotools и все-всем-всем, при этом удобен (сейчас conan вешается к cmake как на корову седло)... IMHO, тут перспективно выглядит build2, но он совсем зеленый (хотя разработчик грамотный) и у него нужно простоту использования доработать (хотя бы уменьшить порог входа). Ну и гибкость добавить (что неизбежно должно произойти при использовании его разными разработчиками с разными потребностями и задачами).

Вряд ли получится сделать пакетный менеджер, который стыкуется с CMake, Autotools

CMake - de facto стандарт для проектов на C++, а autotools - для С проектов с длинной историей. Так что, хочешь не хочешь, а если не поддерживать CMake и autotools, то далеко не уедешь на своём package manager даже, если он будет самый что ни на есть правильный. Поэтому поезд для таких поделок как build2 уже ушёл.