Дружелюбность к новичкам

Все аргументя зачем создавался проект, ролей команды и сравнение с альтернативами — в Зачем odpm. Ниже — быстрый вход для новичка: что установить и с чего начать.

Зачем вообще нужен odpm

Проект odpm создавался для того, чтобы снизить очень высокий порог входа в разработку на платформе Odoo. Речь не о том, чтобы «ещё раз установить Odoo», а о том, чтобы дать человеку готовое рабочее место: открыл каталог в редакторе, написал модуль, запустил обновление — и все пути, зависимости и службы уже согласованы между собой.

Если вы только начинаете, пройдите локальную разработку с нуля или если вы хотите начать со своим репозиторием или репозиторием вашей команды (в нём уже должен быть odpm.json).

«Odoo установлен» и «можно разрабатывать» весьмя далекие друг от друга состояния

Чтобы просто запустить Odoo на Debian - можно поставить системный пакет, на Fedora — .rpm или exe для Windows для указанной версии или собрать окружение по длинной инструкции из интернета. Серивс запустится, в браузере откроется окно входа. И кажется, что «всё готово».

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

Потребность	Почему без odpm это больно
Каталог, где пишется свой код	Каталог установки Odoo из пакета — не место для ваших модулей
Настройки всего окружения в одном логическом месте	Чтобы все части платформы odoo были под ругой и управлялись: Python venv для установки pip пакетов для ваших нужд, docker-compose-файл, переменные среды и т.д.
Системные и Python-пакеты	Часть библитек для сборки python зависимосте ставится в саму систему, часть через pip, непонятно, что откуда и какой версии
Файл конфигурации Odoo	Пути к дополнениям (addons_path), каталог данных — собираются вручную
Исходный код платформы Odoo	Нужен для чтения кода ядра, отладки, осмысленного обновления модулей
Исходники зависимых проектов	OCA, корпоративные репозитории — у каждого свой клон и своя ветка
Согласованные пути к дополнениям	Один пропущенный путь в конфигурации — и вы полчаете сообщени «модуль не найден» без указания ясной причины
Своя кодовая база рядом с зависимостями	Для качественной работы нужно иметь доступ «чужому» каталогу, при код оттуда должен быть доступен для отладки, в этом месте частов возникает путаница с путями в IDE

Сложить это вручную, опираясь только на системные пакеты и разрозненные инструкции, можно, но получается не инструмент для разработчика, а постоянная ручная настройка, которую приходится повторять при смене версии Odoo или компьютера.

Второй уровень сложности: Docker «чтобы у всех было одинаково»

Когда в команде решают запускать Odoo в контейнере, чтобы на Linux, macOS и Windows была одна среда исполнения, задача не упрощается — она удваивается:

• на диске компьютера одни пути, внутри контейнера — другие;
• нужно правильно подключить каталоги с исходниками платформы, проекта и каждой зависимости;
• учесть права пользователя (идентификаторы UID/GID), чтобы файлы не «ломались» между хостом и контейнером;
• в конфигурации Odoo пути к дополнениям должны совпадать с тем, что видит процесс внутри контейнера;
• отдельно настраиваются сетевые порты, база PostgreSQL, а при необходимости еще и отладчик.
• в контейнер иногда надо ставить свои библиотеки pip и использовать их там, при этом еще надо уведомить об этом членов команды

На этом этапе люди чаще всего совершают однотипные ошибки: забытое подключение каталога, неверный путь, зависимость не попала в addons_path, виртуальное окружение пересобрано не там. Не только новичок но и опытный разработчик редко понимает, на каком уровне сломалось — хост, Docker, Odoo, что из зависимостей.

odpm как раз и задуман как слой, который собирает все в единое целое: вы работаете в одном каталоге проекта на диске, описываете состав стека в odpm.json, а odpm клонирует репозитории, генерирует docker-compose, конфигурацию Odoo, подключения каталогов и даёт команды для восстановления базы из архива, установки модулей, смены пароля администратора и отладки в IDE.

Что должно быть на вашем компьютере

На хосте (вашей операционной системе) нужны только:

• Docker — на Windows и macOS обычно Docker Desktop, для Linux лучше ставить именно службу, чтобы Docker там работал нативно без дополнительного слоя виртуализации;
• git;
• установленный odpm — см. раздел установки;
• для разработки и отладки — Visual Studio Code.

Сам Python-проект Odoo и его виртуальное окружение живут в контейнере. Запускать odpm внутри отдельного venv на хосте не нужно — так вы только усложните себе жизнь.

Первые шаги

1. Установите odpm для вашей системы.
2. Пройдите локальную разработку с нуля с репозиторием, в котором уже есть odpm.json.
3. На Windows используйте инструкцию по WSL.

При команде odpm --init сработает мастер первоначальной настройки: он спросит версию Odoo, сценарий использования, каталоги для резервных копий и клонов репозиториев. Если ответ неизвестен — нажимайте Enter, будут подставлены разумные значения по умолчанию.

Краткая формулировка

Установленный из пакетов Odoo запускается, но не даёт готового места для разработки. Исходники платформы и дополнений, пути, окружение Python, конфигурация и единообразие в Docker — отдельная и тяжёлая работа. odpm собирает это в один проектный контур из odpm.json, чтобы вы начинали со своего кода, а не с ручной настройки стека.