Чужой или унаследованный проект¶

Статья для ситуации, когда вы подключаетесь к уже существующему репозиторию с модулями Odoo — со своим odpm.json или без него — а не создаёте окружение «с чистого листа» по учебному демо.

Подготовка каталога окружения¶

Как и при новом проекте, создайте отдельный каталог odpm-окружения (например client_addons-19) и инициализируйте его ссылкой на git:

mkdir client_addons-19 && cd client_addons-19
odpm --init git@github.com:organization/client_addons.git --branch 19.0

Если в корне разрабатываемого репозитория уже есть odpm.json, odpm подхватит версии и зависимости оттуда. Если файла нет — укажите --odoo-version при --init или добавьте odoo_version в репозиторий до подключения.

Как читать сообщения при ошибках¶

Сначала смотрите вывод odpm на хосте — там ошибки подготовки, git и конфигурации. Журнал служб внутри контейнера:

docker compose logs -f

Сообщения интерфейса odpm на хосте могут быть на русском (если задан ODPM_LOCALE=ru_RU). Текстовый журнал Odoo и PostgreSQL в контейнере намеренно остаётся на английском — так проще искать известные ошибки в документации.

Правка описания стека¶

В репозитории разрабатываемого проекта (или в локальной копии после клонирования) правят odpm.json:

dependencies — git-репозитории, от которых зависят модули;
requirements_txt — дополнительные пакеты Python;
при собственном форке ядра — odoo_git_link и platform_name (свой репозиторий платформы).

Форматы ссылок: git, https, file.

Проверка без применения изменений¶

Перед рискованными правками:

odpm plan --skip-start
odpm plan --plan-show-diff --skip-start

Будет показано, какие шаги подготовки выполнились бы и как изменятся docker-compose.yml и служебная конфигурация — без записи на диск и без запуска контейнеров.

Фиксация версий для всей команды¶

После согласования зависимостей ответственный разработчик (координатор) выполняет:

odpm --update-lock --skip-start

и коммитит .odpm/deps.lock.json в репозиторий. Подробнее: deps.lock.json и роль координатора.

Унаследованный data dir PostgreSQL¶

Если каталог data PostgreSQL уже существовал до odpm 4.3 (в логах postgres: Skipping initialization), при первом odpm без файла .odpm/database/last_run.json odpm автоматически:

поднимает PostgreSQL;
создаёт или обновляет роль приложения (odoo);
записывает baseline в last_run.json.

Диагностика:

odpm database status
odpm plan --skip-start

Если роль отсутствует, а adoption ещё не сработал:

odpm database ensure-role

Смена POSTGRES_SERVICE_NAME или порта в .env даёт drift относительно снимка — odpm предупредит в plan. После переименования сервиса удалите orphan-контейнеры: docker compose down --remove-orphans.

Adoption не меняет владельца существующих Odoo-баз в PostgreSQL. Для --db-drop / --db-restore на таких базах см. состояние PostgreSQL.

Частые затруднения¶

Несовместимые версии во вложенных odpm.json зависимостей: в режиме разработчика — предупреждение, в сценарии ci — ошибка.
Нет доступа по SSH к приватному git: настройте ~/.ssh или укажите PATH_TO_SSH_KEY в .env (переменные окружения).
Долгое первое клонирование платформы Odoo — нормально; повторные запуски существенно быстрее.