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

Все, кто плотно сидит на 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 проста как валенок. Но у нее есть фатальные недостатки:

1. Сложность версионирования: Переключаться между ветками или тегами через аргументы командной строки неудобно.

2. Отсутствие прослеживаемости (traceability): В lock-файле проекта никак не отражалось, какая именно версия конфига использовалась для сборки бинарника.

3. Гетерогенные среды: Если у вас часть разработчиков на Windows, а часть на Linux, приходилось городить скрипты внутри репозитория с конфигами, чтобы не подсунуть «никсовые» настройки в PowerShell.

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

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

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

Рецепт (conanfile.py ^[1]) для конфигурации выглядит до смешного просто. Главное — указать 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)
 [2]

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

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

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

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

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

conan config install-pkg "my_team_config/[>=1.2 <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:
 [2]

Установили конфиг версии 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
 [2]

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

conan config install-pkg
 [2]

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

Итоги

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

• Единый механизм доставки (тот же Artifactory, те же права доступа).

• Прозрачное управление зависимостями через диапазоны версий.

• Гарантию того, что "бинарник вчера" и "бинарник сегодня" собраны в идентичной среде