Компания JFrog объявила о скором закрытии сервисов Bintray, JCenter, GoCenter и ChartCenter

И Conan соберёт ее и сгенерирует файлы так, что она встроится в мою систему сборки (cmake, meson, you name it) естественным образом, со всеми необходимыми транзитивными зависимостями.

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

Готовое Conan точно умеет хранить.

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

И по запросу собирает, как vcpkg. Как по мне vcpkg сделан лучше (без Python), но отсутствие поддержки версий всё портит.

Я вот в bintray deb-пакеты выкладывал. Непонятно куда теперь их девать.

Можно на гитхаб. Можно свой сервач поднять (если для проекта) и там и файло и сайт хостить.

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

А в билд каталоге проекта будут только ссылки (-I/-L на кеш итд).

Этот кеш как раз и загружается в bintray (или аналогичное on prem). Просто проблема в том, что вариантов разных флагов и настроек очень много и очень часто они не подходят, поэтому все равно надо самому собирать (точнее сказать ему, чтобы собрал то, что не смог в бинтрее найти). Поэтому и назвали «сизифовым трудом».

А чем питон так плох? Имнип vcpkg абьюзит cmake, а у него синтаксис тоже много споров вызывает.

Он не плох, он просто лишний. Cmake используется и в Conan.

есть там поддержка версий.

Вот почитай: https://github.com/microsoft/vcpkg/blob/cb7a38729ef1460c53bb166df81e9c27cef5e23d/docs/users/versioning.getting-started.md

Наш проект ровно в такой же ситуации, и, пока обсуждали альтернативы, к нам внезапно пришел CTO из Cloudsmith и предложил их предложением воспользоваться. Open source проектам дают 500GB и можно ни в чем себе не отказывать. Умеют огромное количество стандартов репозитариев (.deb в том числе) и вообще выглядят пока весьма позитивно.

Ну значит завезли таки этот их registries-2 с идиотскими git-tree хешами:

https://github.com/microsoft/vcpkg/blob/master/docs/specifications/registries-2.md#git-registry-databases

Это сколько же теперь будет гемороя поддерживать такие версии? А ведь могли вынести содержимое /ports в git submodules и не изобретать этот registries-2 велосипед.

Так и сейчас нанимаем, как не в себя: https://join.jfrog.com/?office=netanya-tel-aviv-israel&department=rd#filter

Не очень понял, почему я должен возвращаться в Израиль теперь?

Я не сказал, что должен. Я лишь предположил, что это может случиться.

Оу, интересно. Спасибо.

Наличие альтернативы альтернативы - это лучше, чем ее отсутствие. Очень жаль, что например Codehaus почил… :(

Так и сейчас нанимаем, как не в себя

Блин, этот слоган в промо ролике по ссылке «Imagine there are no more software versions» - это просто пять: действительно, после 1 мая их и не будет! :D

Ты помрешь раньше раньше чем жабка.

А как теперь Gradle-проекты на JCenter будут работать?