Все, кто плотно сидит на C++ и использует Conan, знают: сам по себе пакетный менеджер — это только полдела. Настоящее веселье начинается, когда нужно раскатать одинаковые настрйки на всю команду и десяток CI-нод. Репозитории, профили, хуки, кастомные настройки всё это хозяйство нужно как-то синхронизировать.

Раньше у нас был conan config install, который тянул конфиги из git-репозитория или zip-архива. Решение рабочее, но с душком: попробуйте воспроизвести сборку двухлетней давности, если за это время мастер-ветка с конфигами улетела далеко вперед.

В Conan версии 2.x (и последних минорных обновлениях) завезли киллер-фичу: conan config install-pkg. Теперь конфигурация — это полноценный пакет. Давайте разберемся, почему это меняет правила игры.

В чем проблема «старого» подхода?

Команда conan config install git@github.com/myorg/conan-config.git проста как валенок. Но у нее есть фатальные недостатки:

Сложность версионирования: Переключаться между ветками или тегами через аргументы командной строки неудобно.
Отсутствие прослеживаемости (traceability): В lock-файле проекта никак не отражалось, какая именно версия конфига использовалась для сборки бинарника.
Гетерогенные среды: Если у вас часть разработчиков на Windows, а часть на Linux, приходилось городить скрипты внутри репозитория с конфигами, чтобы не подсунуть «никсовые» настройки в PowerShell.

Теперь конфигурация — это First-class citizen

С приходом install-pkg мы упаковываем настройки в стандртный Conan-пакет. Это значит, что для конфигов теперь работают версии, семантическое версионирование (SemVer), диапазоны (version ranges) и, самое главное, ревизии.

Как приготовить такой пакет?

Рецепт (conanfile.py) для конфигурации выглядит до смешного просто. Главное — указать package_type = "configuration"

from conan import ConanFile
from conan.tools.files import copy
import os

class MyGlobalConfig(ConanFile):
    name = "my_team_config"
    version = "1.2.0"
    package_type = "configuration"

    # Если нужно разделять конфиги по ОС
    settings = "os"

    def package(self):
        # Копируем профили, хуки и глобальный conf
        subdir = "win" if self.settings.os == "Windows" else "nix"
        copy(self, "*", src=os.path.join(self.source_folder, subdir), 
             dst=self.package_folder)

Заливаем это в свой Artifactory как обычную библиотеку:

conan export-pkg . -s os=Linux
conan upload my_team_config/1.2.0 -r my_remote

Почему это круто?

1. Версионный контроль на стероидах

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

conan config install-pkg "my_team_config/[>=1.2 <2]"

Если в репозитории выйдет патч 1.2.1, команда обновления сама подтянет актуальные настройки.

2. Полная воспроизводимость через Lock-файлы

Это то, чего нам не хватало. Теперь, когда вы создаете lock-файл для проекта, Conan записывает туда не только верси библиотек (OpenSSL, Boost и т.д.), но и точную ревизию пакета конфигурации.
Если через три месяца прилетит баг, вы сможете развернуть окружение с точно такими же хуками и профилями, какие были в момент релиза.

3. Магия с Package ID

В Conan есть хитрая настройка core.package_id:config_mode. Если её включить, версия вашего конфига начнет влиять на package_id всех собираемых пакетов.

# В вашем global.conf
core.package_id:config_mode=minor_modeУстановили конфиг версии 1.2.0 — собрали бинарники. Обновились до 1.3.0 (где, допустим, изменились флаги компилятора по умолчанию) — Conan поймет, что старые бинарники больше не валидны, и инициирует пересборку. Это уровень контроля, недоступный при обычном config install.
Автоматизация через conanconfig.yml
Чтобы не заставлять разработчиков вбивать длинные команды, в корне проекта (или репозитория с конфигами) можно положить файл conanconfig.yml:

Установили конфиг версии 1.2.0 — собрали бинарники. Обновились до 1.3.0 (где, допустим, изменились флаги компилятора по умолчанию) — Conan поймет, что старые бинарники больше не валидны, и инициирует пересборку. Это уровень контроля, недоступный при обычном config install.

Автоматизация через conanconfig.yml

Чтобы не заставлять разработчиков вбивать длинные команды, в корне проекта (или репозитория с конфигами) можно положить файл conanconfig.yml:

Теперь достаточно просто написать:
packages:
  - my_team_config/[>=1.0]
  - custom_hooks/1.2@enterprise/stable
urls:
  - https://my-artifactory.local/api/conan/repo

Теперь достаточно просто написать:

conan config install-pkg

Conan сам найдет файл, сходит в нужные репозитории и раскатает настройки. А если добавить к этому .conanrc с определением conan_home = ./.conan, можно добиться полной изоляции окружения для каждого конкретного проекта.

Итоги

Переход от Git-ориентированного конфига к пакетному — это логичный шаг в эволюции Conan. Мы получаем:

Единый механизм доставки (тот же Artifactory, те же права доступа).
Прозрачное управление зависимостями через диапазоны версий.
Гарантию того, что "бинарник вчера" и "бинарник сегодня" собраны в идентичной среде

Конфигурация как пакет: наводим порядок в Conan так, чтобы не было мучительно больно