А именно: есть ощущение, что Conan существует не для решения проблем разработчиков, а для привлечения клиентов к сервисам JFrog.
Возможно, я сильно не прав. Но вот на третий день попыток освоить и изучить Conan у меня пока именно такое ощущение. И подталкивают меня к этому три фактора.
Фактор первый. Происхождение и развитие Conan-а. Если правильно помню, то сперва был biicode. Который некие чуваки, кажется, из Испании, пытались позиционировать как сервис для управления зависимостями в C++. Причем сервис как бизнес. Тема вполне ожидаемо не взлетела. Что не удивительно в наш век бесплатного OpenSource-инструментария. Далее biicode приказал долго жить, а на его руинах начал развиваться проект Conan. Который, имхо, ждала бы судьба biicode, если бы команду разработчиков Conan-а не взяла на борт JFrog.
Фактор второй. Conan пытается угодить всем. Могу ошибаться, но изначально Conan, как и его предтеча, biicode, был заточен под CMake. Но потом в Conan-е от завязки исключительно на CMake отошли и сейчас в документации к Conan говорится, что Conan перпендикулярен системам сборки. Мол, задача Conan-а только подтащить к вам на машину нужные вам артефакты, а дальше вы любитесь с этими артефактами любым удобным для вас способом. Хоть с CMake, хоть с Autotools, хоть еще с чем-нибудь.
Что лично мне непонятно от слова совсем: какой толк в "централизованном" репозитории зависимостей, если там перемешаны зависимости с разными системами сборки. Скажем, у меня в проекте Waf, а из Conan-а я беру три артифакта, первый из которых завязан на CMake, второй на GNU Makefiles, а третий на SCons. И что с этим винигретом мне потом делать? В этом плане подход vcpkg, hunter-а, build2 и buckaroo лично мне представляется гораздо более логичным и практичным.
Зато "всеядность" Conan-а на 100% оправдывается, если целью является привлечение как можно большего числа пользователей к JFrog Artifactory. Чтобы затем часть из них стала платными пользователями.
Ведь мир C++ неоднороден, CMake пока любим и используем не всеми. Значит, если Conan будет поддерживать только CMake (как тот же vcpkg), то круг потенциальных клиентов резко сужается. Поэтому нужно сделать Conan привлекательным и для тех, кто CMake пока еще не пользуется. Какая в итоге будет выгода пользователям Conan-а -- это другой вопрос, главный вопрос -- это сколько пользователей прибегут на сервисы JFrog-а.
Фактор третий. Есть ощущение, что проект развивается, что называется "без руля и без ветрил". Т.е. JFrog взял команду Conan-а на борт, а дальше дал им карт бланш и простую цель: сделайте так, чтобы ваш Conan приводил C++ников на наши сервисы. Как вы это будете делать никого ниипет не интересует, важен результат. Вот команда и творит хер знает что.
Лично мне сложно объяснить качество и понятность документации как-то иначе. Они, наверняка, сами не ставили себя на место обычного пользователя, который по этой документации должен был бы их инструмент освоить. Такое ощущение, что смотрели просто на объем: как-то мало, давайте еще текста вольем. Влили. Лучше или хуже стало? Да похеру, главное, что стало больше, солиднее.
Я бы своим коллегам/подчиненным за такого качества документацию руки бы давно поотбивал. И заставил бы переделывать до тех пор, пока бы документацию не привели к надлежащему состоянию. Тут же, наверное, жесткого лидера с четким видением цели нет.
PS. В общем, продолжаю погружаться в чан с говном в Conan. Раз уж взялся за то, чтобы сделать пакеты для Conan, нужно довести до логического завершения. Либо таки сделать. Либо обосновать раз и навсегда, почему пакеты Conan-а вместе с Conan-ом стройными рядами идут в /dev/null. И потом, наверное, напишу свое нелицеприятное мнение о vcpkg и Conan-е.
Комментариев нет:
Отправить комментарий