odoo-devops-tools 1.20.2__tar.gz → 1.20.4__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: odoo-devops-tools
3
- Version: 1.20.2
3
+ Version: 1.20.4
4
4
  Summary: A small set of utilities for local Odoo development and simple Odoo deployments.
5
5
  Author: Roman Lacko
6
6
  License-Expression: MIT
@@ -52,7 +52,7 @@ From this configuration, `odt-env` can generate a workspace such as:
52
52
  ```text
53
53
  ROOT/
54
54
  ├── docker/ # generated Docker artifacts
55
- │ ├── local/ # local Docker artifacts
55
+ │ ├── local/ # Docker workflow artifacts
56
56
  │ │ └── scripts/ # database and filestore backup/restore helpers
57
57
  │ └── deploy/ # self-contained deploy build context
58
58
  ├── odoo/ # Odoo source
@@ -66,7 +66,7 @@ ROOT/
66
66
  ├── odoo-backups/ # backups created by helper scripts
67
67
  ├── wheelhouse/ # offline Python wheelhouse
68
68
  ├── venv/ # Python virtual environment
69
- ├── compose.yaml # local Docker Compose file
69
+ ├── compose.yaml # Docker Compose file
70
70
  └── odoo-project.ini # workspace configuration
71
71
  ```
72
72
 
@@ -106,16 +106,16 @@ odt-env --help
106
106
 
107
107
  ---
108
108
 
109
- ## Quick start
109
+ ## Usage
110
110
 
111
111
  `odt-env` supports two development workflows:
112
112
 
113
- - **Local Docker** — run Odoo and PostgreSQL with the generated Docker Compose environment.
113
+ - **Docker workflow** — run Odoo and PostgreSQL with the generated Docker Compose environment.
114
114
  - **Native development with venv** — run Odoo directly on the host using a generated Python virtual environment.
115
115
 
116
116
  Choose the workflow that fits your environment. Both use the same `odoo-project.ini` project definition.
117
117
 
118
- ### Local Docker
118
+ ## 1. Docker workflow
119
119
 
120
120
  Create a new workspace:
121
121
 
@@ -141,39 +141,7 @@ docker compose run --rm odoo -- -c /etc/odoo/odoo.conf -d odoo \
141
141
 
142
142
  Docker Compose runs both Odoo and PostgreSQL. Odoo is available at http://localhost:8069.
143
143
 
144
- ### Native development with venv
145
-
146
- In this workflow, Odoo runs directly on the host using a generated Python virtual environment.
147
-
148
- Create the workspace with the Odoo source and virtual environment:
149
-
150
- ```bash
151
- odt-env --init-project ./odoo19 --sync-all --create-venv \
152
- --set config:db_host=127.0.0.1 \
153
- --set config:db_name=odoo \
154
- --set config:db_user=odoo \
155
- --set config:db_password=odoo
156
- ```
157
-
158
- > **Note**
159
- > Make sure PostgreSQL is running at the configured host and the configured database user exists.
160
-
161
- Start Odoo with the generated script:
162
-
163
- ```bash
164
- cd ./odoo19
165
- ./odoo-scripts/run.sh
166
- ```
167
-
168
- Odoo starts with the generated configuration from `./odoo-configs/odoo-server.conf` and is available at http://localhost:8069.
169
-
170
- ---
171
-
172
- ## Usage
173
-
174
- The examples below use the same workspace configuration introduced in the Quick start section. Docker-specific and native-specific steps are separated where they differ.
175
-
176
- The default `odoo-project.ini` contains:
144
+ The Docker workflow uses the following `odoo-project.ini` configuration:
177
145
 
178
146
  ```ini
179
147
  [virtualenv]
@@ -196,17 +164,15 @@ base_image = odoo:19.0
196
164
  [config]
197
165
  ```
198
166
 
199
- The local Docker workflow can use this configuration as-is. The native quick start adds the PostgreSQL connection settings to `[config]` through `--set`.
200
-
201
167
  Edit this file when you want to add extra addons, change configuration values, pin repositories, or adjust Python dependency handling.
202
168
 
203
- ### 1. Adding extra addons
169
+ ### 1.1. Adding extra addons
204
170
 
205
171
  To extend Odoo with additional functionality, add extra addons through `[addons.<name>]` sections in `odoo-project.ini`.
206
172
 
207
173
  In this example, we add two Git-based addon repositories, `OCA/web` and `OCA/helpdesk`.
208
174
 
209
- #### 1.1. Update the project file
175
+ #### 1.1.1. Update the project file
210
176
 
211
177
  Edit `odoo-project.ini` in the workspace root and add these addon sections:
212
178
 
@@ -222,9 +188,10 @@ branch = ${odoo:version}
222
188
 
223
189
  The rest of the generated project file can stay unchanged.
224
190
 
225
- #### 1.2. Local Docker
191
+ #### 1.1.2. Sync and install addons
192
+
226
193
 
227
- Sync the configured addon repositories and refresh the generated local Docker artifacts:
194
+ Sync the configured addon repositories and refresh the generated Docker workflow artifacts:
228
195
 
229
196
  ```bash
230
197
  odt-env --sync-addons
@@ -233,7 +200,7 @@ docker compose up --build -d
233
200
 
234
201
  The addon repositories are cloned into `ROOT/odoo-addons/oca-web/` and `ROOT/odoo-addons/oca-helpdesk/` and bind-mounted into the Odoo container.
235
202
 
236
- If an addon source contains a `requirements.txt` file, its Python dependencies are included when the local Docker image is rebuilt.
203
+ If an addon source contains a `requirements.txt` file, its Python dependencies are included when the Docker image is rebuilt.
237
204
 
238
205
  Install the modules from the newly added addon repositories:
239
206
 
@@ -250,33 +217,9 @@ For subsequent addon updates, run `click-odoo-update` inside the Odoo container:
250
217
  docker compose exec odoo click-odoo-update -c /etc/odoo/odoo.conf -d odoo
251
218
  ```
252
219
 
253
- #### 1.3. Native development with venv
254
-
255
- Sync the sources and recreate the Python environment so dependencies from the new addon repositories are included:
256
-
257
- ```bash
258
- odt-env --sync-all --create-venv
259
- ```
260
-
261
- The addon repositories are cloned into `ROOT/odoo-addons/oca-web/` and `ROOT/odoo-addons/oca-helpdesk/`, and their directories are added to the generated `addons_path`.
262
-
263
- Start Odoo and install the modules from the newly added addon repositories:
264
-
265
- ```bash
266
- ./odoo-scripts/run.sh -i web_notify,helpdesk_mgmt
267
- ```
268
-
269
- For subsequent addon updates, use the generated update script:
270
-
271
- ```bash
272
- ./odoo-scripts/update.sh
273
- ```
274
-
275
- The generated script uses `click-odoo-update` with the workspace Odoo configuration.
276
-
277
- ### 2. Local Docker backup and restore
220
+ ### 1.2. Backup and restore
278
221
 
279
- The Local Docker workflow generates Unix shell helpers under `ROOT/docker/local/scripts/` for backing up and restoring the PostgreSQL database and Odoo filestore independently:
222
+ The Docker workflow generates Unix shell helpers under `ROOT/docker/local/scripts/` for backing up and restoring the PostgreSQL database and Odoo filestore independently:
280
223
 
281
224
  ```text
282
225
  docker/local/scripts/
@@ -297,7 +240,7 @@ The default database name is taken from `[config].db_name` when configured, othe
297
240
  ODOO_DB_NAME=odoo_test ./docker/local/scripts/backup-db.sh
298
241
  ```
299
242
 
300
- #### 2.1. Database backup
243
+ #### 1.2.1. Database backup
301
244
 
302
245
  Create a PostgreSQL custom-format dump under `ROOT/odoo-backups/`:
303
246
 
@@ -317,7 +260,7 @@ Pass an output path explicitly when needed:
317
260
  ./docker/local/scripts/backup-db.sh ./odoo-backups/pre-upgrade.dump
318
261
  ```
319
262
 
320
- #### 2.2. Database restore
263
+ #### 1.2.2. Database restore
321
264
 
322
265
  Restore a database dump with `pg_restore`:
323
266
 
@@ -339,7 +282,7 @@ To restore the same dump into another database without replacing the default dat
339
282
  ODOO_DB_NAME=odoo_restore ./docker/local/scripts/restore-db.sh ./odoo-backups/pre-upgrade.dump
340
283
  ```
341
284
 
342
- #### 2.3. Filestore backup
285
+ #### 1.2.3. Filestore backup
343
286
 
344
287
  Create a compressed tar archive of the selected database filestore:
345
288
 
@@ -370,7 +313,7 @@ docker compose stop odoo
370
313
  docker compose up -d odoo
371
314
  ```
372
315
 
373
- #### 2.4. Filestore restore
316
+ #### 1.2.4. Filestore restore
374
317
 
375
318
  Restore a filestore archive:
376
319
 
@@ -394,11 +337,11 @@ ODOO_DB_NAME=odoo_restore ./docker/local/scripts/restore-filestore.sh ./odoo-bac
394
337
 
395
338
  Database and filestore backups are intentionally separate. This allows either part to be restored independently while still making it possible to create matching database and filestore backups when both are needed.
396
339
 
397
- #### 2.5. Restic filestore backup
340
+ #### 1.2.5. Restic filestore backup
398
341
 
399
342
  The generated Docker image also includes `restic`, installed from the base image APT repositories. Restic is an additional option intended especially for large filestores where incremental snapshots and deduplication are useful.
400
343
 
401
- The Local Docker workflow generates three additional helpers:
344
+ The Docker workflow generates three additional helpers:
402
345
 
403
346
  ```text
404
347
  docker/local/scripts/restic.sh
@@ -442,7 +385,7 @@ List or inspect snapshots through the generic wrapper:
442
385
  ./docker/local/scripts/restic.sh check
443
386
  ```
444
387
 
445
- #### 2.6. Restic filestore restore
388
+ #### 1.2.6. Restic filestore restore
446
389
 
447
390
  Restore the latest matching filestore snapshot:
448
391
 
@@ -468,9 +411,8 @@ ODOO_DB_NAME=odoo_restore RESTIC_SOURCE_DB_NAME=odoo ./docker/local/scripts/rest
468
411
 
469
412
  The restore helper removes the target database filestore before restoring it. When `latest` is used, the snapshot selection is restricted to the current `RESTIC_HOST` and source filestore path. Use the same `RESTIC_HOST` value that was used when the snapshot was created if the restore is performed from another host.
470
413
 
471
- ---
472
414
 
473
- ### 3. Creating a Docker deploy build context
415
+ ### 1.3. Creating a Docker deploy build context
474
416
 
475
417
  Use `--create-docker-deploy` to generate a self-contained Docker build context for CI/CD, testing, staging, production, or another non-local deployment workflow.
476
418
 
@@ -500,9 +442,9 @@ Addon modules are staged under `docker/deploy/addons/` and copied into `/mnt/ext
500
442
  docker build -t mycompany/odoo:19.0 docker/deploy
501
443
  ```
502
444
 
503
- `[docker].base_image` controls the base image used by both local and deploy Dockerfiles.
445
+ `[docker].base_image` controls the base image used by both generated Dockerfiles.
504
446
 
505
- In CI, where the local Docker context is unnecessary, combine the options:
447
+ In CI, where the `docker/local/` context is unnecessary, combine the options:
506
448
 
507
449
  ```bash
508
450
  odt-env --sync-addons --create-docker-deploy --no-local-docker
@@ -511,57 +453,114 @@ docker build -t mycompany/odoo:19.0 docker/deploy
511
453
 
512
454
  ---
513
455
 
514
- ### 4. Managing Python requirements
456
+ ## 2. Native development with venv
515
457
 
516
- The `[virtualenv]` section controls additional Python dependencies used when provisioning both the native virtual environment and generated Docker images.
458
+ In this workflow, Odoo runs directly on the host using a generated Python virtual environment.
517
459
 
518
- Use it to add new packages, pin specific versions, and override packages collected from Odoo or addon repository `requirements.txt` files.
460
+ Create the workspace with the Odoo source and virtual environment:
519
461
 
520
- Use:
462
+ ```bash
463
+ odt-env --init-project ./odoo19 --sync-all --create-venv \
464
+ --set config:db_host=127.0.0.1 \
465
+ --set config:db_name=odoo \
466
+ --set config:db_user=odoo \
467
+ --set config:db_password=odoo
468
+ ```
521
469
 
522
- - `requirements` to add extra packages or pin an explicit version
523
- - `requirements_ignore` to skip packages that would otherwise be collected from repository requirements files
470
+ > **Note**
471
+ > Make sure PostgreSQL is running at the configured host and the configured database user exists.
524
472
 
525
- When a package is listed in `requirements`, `odt-env` automatically gives that package priority by ignoring the same package name from collected repository requirements. This means you can usually pin a package version just by adding it to `requirements`.
473
+ Start Odoo with the generated script:
474
+
475
+ ```bash
476
+ cd ./odoo19
477
+ ./odoo-scripts/run.sh
478
+ ```
526
479
 
527
- #### 4.1. Add or pin packages
480
+ Odoo starts with the generated configuration from `./odoo-configs/odoo-server.conf` and is available at http://localhost:8069.
528
481
 
529
- Use `requirements` to install additional packages or to force a specific version:
482
+ The native workflow uses the following `odoo-project.ini` configuration, with PostgreSQL connection settings added to `[config]`:
530
483
 
531
484
  ```ini
532
485
  [virtualenv]
486
+ managed_python = true
487
+ python_version =
488
+ build_constraints =
533
489
  requirements =
534
- requests==2.32.3
535
- boto3==1.35.99
490
+ requirements_ignore =
491
+
492
+ [odoo]
493
+ version = 19.0
494
+ repo = https://github.com/odoo/odoo.git
495
+ branch = 19.0
496
+ commit =
497
+ shallow = true
498
+
499
+ [docker]
500
+ base_image = odoo:19.0
501
+
502
+ [config]
503
+ db_host = 127.0.0.1
504
+ db_name = odoo
505
+ db_user = odoo
506
+ db_password = odoo
536
507
  ```
537
508
 
538
- In this example, both packages are included in the generated dependency set and pinned to the specified versions.
509
+ Edit this file when you want to add extra addons, change configuration values, pin repositories, or adjust Python dependency handling.
539
510
 
540
- #### 4.2. Override a package with a different one
511
+ ### 2.1. Adding extra addons
541
512
 
542
- If you want to replace a package with a different distribution name, add the replacement to `requirements` and skip the original package with `requirements_ignore`.
513
+ To extend Odoo with additional functionality, add extra addons through `[addons.<name>]` sections in `odoo-project.ini`.
543
514
 
544
- Example:
515
+ In this example, we add two Git-based addon repositories, `OCA/web` and `OCA/helpdesk`.
516
+
517
+ #### 2.1.1. Update the project file
518
+
519
+ Edit `odoo-project.ini` in the workspace root and add these addon sections:
545
520
 
546
521
  ```ini
547
- [virtualenv]
548
- requirements =
549
- psycopg2-binary==2.9.9
550
- requirements_ignore =
551
- psycopg2
522
+ [addons.oca-web]
523
+ repo = https://github.com/OCA/web.git
524
+ branch = ${odoo:version}
525
+
526
+ [addons.oca-helpdesk]
527
+ repo = https://github.com/OCA/helpdesk.git
528
+ branch = ${odoo:version}
552
529
  ```
553
530
 
554
- In this example, `odt-env` installs `psycopg2-binary==2.9.9` and skips `psycopg2` when collecting repository requirements.
531
+ The rest of the generated project file can stay unchanged.
555
532
 
556
- ---
533
+ #### 2.1.2. Sync and install addons
534
+
535
+ Sync the sources and recreate the Python environment so dependencies from the new addon repositories are included:
536
+
537
+ ```bash
538
+ odt-env --sync-all --create-venv
539
+ ```
540
+
541
+ The addon repositories are cloned into `ROOT/odoo-addons/oca-web/` and `ROOT/odoo-addons/oca-helpdesk/`, and their directories are added to the generated `addons_path`.
542
+
543
+ Start Odoo and install the modules from the newly added addon repositories:
544
+
545
+ ```bash
546
+ ./odoo-scripts/run.sh -i web_notify,helpdesk_mgmt
547
+ ```
548
+
549
+ For subsequent addon updates, use the generated update script:
557
550
 
558
- ### 5. Using system Python instead of managed Python
551
+ ```bash
552
+ ./odoo-scripts/update.sh
553
+ ```
554
+
555
+ The generated script uses `click-odoo-update` with the workspace Odoo configuration.
556
+
557
+ ### 2.2. Using system Python instead of managed Python
559
558
 
560
559
  By default, `odt-env` uses `uv` to install and manage the requested Python version.
561
560
 
562
561
  If you already have a suitable system Python installed, you can disable managed Python.
563
562
 
564
- #### 5.1. Update the project file
563
+ #### 2.2.1. Update the project file
565
564
 
566
565
  Disable managed Python by adding `python_version = 3.11` and `managed_python = false` to the `odoo-project.ini` file.
567
566
 
@@ -575,7 +574,7 @@ managed_python = false
575
574
  python_version = 3.11
576
575
  ```
577
576
 
578
- #### 5.2. Update the workspace
577
+ #### 2.2.2. Update the workspace
579
578
 
580
579
  After changing the project file, run `odt-env` again from the workspace root:
581
580
 
@@ -585,9 +584,157 @@ odt-env --sync-all --create-venv
585
584
 
586
585
  This recreates the virtual environment at `ROOT/venv` using the system Python.
587
586
 
587
+ ### 2.3. Script reference
588
+
589
+ This section describes the native helpers under `ROOT/odoo-scripts/`. Docker backup/restore helpers are documented in the Docker workflow section above.
590
+
591
+ Most helper scripts are generated in both Unix (`.sh`) and Windows (`.bat`) variants. `instance.sh` is available only on Unix-like systems.
592
+
593
+ Native database backup and restore scripts are generated only when `[config].db_name` is configured.
594
+
595
+ The examples below use the Unix form.
596
+
597
+ #### 2.3.1. run
598
+
599
+ Starts Odoo in the foreground.
600
+
601
+ Any extra arguments are forwarded to the underlying command `odoo-bin`.
602
+
603
+ Examples:
604
+
605
+ ```bash
606
+ ./odoo-scripts/run.sh
607
+ ./odoo-scripts/run.sh --dev=all
608
+ ./odoo-scripts/run.sh -i sale,crm --without-demo=all
609
+ ```
610
+
611
+ #### 2.3.2. instance
612
+
613
+ Manages Odoo as a background service on Unix-like systems.
614
+
615
+ Logs are written to `ROOT/odoo-logs/odoo-server.log` and the PID is stored in `ROOT/odoo-logs/odoo-server.pid`.
616
+
617
+ Examples:
618
+
619
+ ```bash
620
+ ./odoo-scripts/instance.sh start
621
+ ./odoo-scripts/instance.sh stop
622
+ ./odoo-scripts/instance.sh restart
623
+ ./odoo-scripts/instance.sh status
624
+ ```
625
+
626
+ #### 2.3.3. test
627
+
628
+ Runs Odoo tests.
629
+
630
+ The script always adds `--test-enable --stop-after-init`.
631
+
632
+ Any extra arguments are forwarded to the underlying command `odoo-bin`.
633
+
634
+ Examples:
635
+
636
+ ```bash
637
+ ./odoo-scripts/test.sh
638
+ ./odoo-scripts/test.sh -i sale --test-tags /sale
639
+ ```
640
+
641
+ #### 2.3.4. shell
642
+
643
+ Opens an Odoo shell.
644
+
645
+ Examples:
646
+
647
+ ```bash
648
+ ./odoo-scripts/shell.sh
649
+ ```
650
+
651
+ #### 2.3.5. backup
652
+
653
+ Creates a timestamped ZIP backup under `ROOT/odoo-backups/`.
654
+
655
+ Any extra arguments are forwarded to the underlying command `click-odoo-backupdb` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-backupdb-beta) package.
656
+
657
+ Examples:
658
+
659
+ ```bash
660
+ ./odoo-scripts/backup.sh
661
+ ```
662
+
663
+ #### 2.3.6. restore
664
+
665
+ Restores a backup into the configured database.
666
+
667
+ The script always adds `--copy --neutralize`.
668
+
669
+ Any extra arguments are forwarded to the underlying command `click-odoo-restoredb` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-restoredb-beta) package.
670
+
671
+ Examples:
672
+
673
+ ```bash
674
+ ./odoo-scripts/restore.sh ./odoo-backups/odoo_20260331_221443.zip
675
+ ./odoo-scripts/restore.sh ./odoo-backups/odoo_20260331_221443.zip --force
676
+ ```
677
+
678
+ #### 2.3.7. update
679
+
680
+ Updates an Odoo database automatically detecting addons to update based on a hash of their file content.
681
+
682
+ Any extra arguments are forwarded to the underlying command `click-odoo-update` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-update-stable) package.
683
+
684
+ Examples:
685
+
686
+ ```bash
687
+ ./odoo-scripts/update.sh
688
+ ./odoo-scripts/update.sh --update-all
689
+ ```
690
+
691
+ ---
692
+
693
+ ## 3. Managing Python requirements
694
+
695
+ The `[virtualenv]` section controls additional Python dependencies used when provisioning both the native virtual environment and generated Docker images.
696
+
697
+ Use it to add new packages, pin specific versions, and override packages collected from Odoo or addon repository `requirements.txt` files.
698
+
699
+ Use:
700
+
701
+ - `requirements` to add extra packages or pin an explicit version
702
+ - `requirements_ignore` to skip packages that would otherwise be collected from repository requirements files
703
+
704
+ When a package is listed in `requirements`, `odt-env` automatically gives that package priority by ignoring the same package name from collected repository requirements. This means you can usually pin a package version just by adding it to `requirements`.
705
+
706
+ ### 3.1. Add or pin packages
707
+
708
+ Use `requirements` to install additional packages or to force a specific version:
709
+
710
+ ```ini
711
+ [virtualenv]
712
+ requirements =
713
+ requests==2.32.3
714
+ boto3==1.35.99
715
+ ```
716
+
717
+ In this example, both packages are included in the generated dependency set and pinned to the specified versions.
718
+
719
+ ### 3.2. Override a package with a different one
720
+
721
+ If you want to replace a package with a different distribution name, add the replacement to `requirements` and skip the original package with `requirements_ignore`.
722
+
723
+ Example:
724
+
725
+ ```ini
726
+ [virtualenv]
727
+ requirements =
728
+ psycopg2-binary==2.9.9
729
+ requirements_ignore =
730
+ psycopg2
731
+ ```
732
+
733
+ In this example, `odt-env` installs `psycopg2-binary==2.9.9` and skips `psycopg2` when collecting repository requirements.
734
+
588
735
  ---
589
736
 
590
- ### 6. Creating portable workspace bundles
737
+ ## 4. Creating portable workspace bundles
591
738
 
592
739
  Portable bundles are useful when you want to prepare an Odoo workspace on an internet-connected machine and reproduce it on another compatible machine without cloning repositories or downloading Python packages again.
593
740
 
@@ -605,7 +752,7 @@ The bundle does not contain the virtual environment, database data, logs, backup
605
752
 
606
753
  Those machine-specific outputs are recreated on the target machine.
607
754
 
608
- #### 6.1. Create a bundle on the build machine
755
+ ### 4.1. Create a bundle on the build machine
609
756
 
610
757
  On an internet-connected build machine, sync the sources, build the wheelhouse, and create the bundle in one command:
611
758
 
@@ -625,7 +772,7 @@ You can also select an explicit output file:
625
772
  odt-env --sync-all --create-venv --create-bundle ./artifacts/odoo18-production.odt.zip
626
773
  ```
627
774
 
628
- #### 6.1.1. Including uncommitted changes
775
+ #### 4.1.1. Including uncommitted changes
629
776
 
630
777
  By default, bundle creation stops when a bundled Git repository has uncommitted changes.
631
778
 
@@ -635,7 +782,7 @@ To intentionally include those changes in the bundle, use:
635
782
  odt-env --sync-all --create-venv --create-bundle --allow-dirty-bundle
636
783
  ```
637
784
 
638
- #### 6.2. Create the workspace on the target machine
785
+ ### 4.2. Create the workspace on the target machine
639
786
 
640
787
  Copy the ZIP to the target machine and import it into an empty directory:
641
788
 
@@ -662,7 +809,7 @@ The import operation:
662
809
  > **Compatibility note**
663
810
  > A wheelhouse is platform- and architecture-dependent. Create and import a bundle on compatible systems, for example Linux x86-64 to Linux x86-64. The target machine must have `uv` and access to the configured Python version. When `[virtualenv].managed_python = true`, `uv` may still need network access if that Python interpreter is not already installed or cached. For a fully disconnected target, install the required Python interpreter beforehand or use `managed_python = false`.
664
811
 
665
- #### 6.3. Manual wheelhouse workflow
812
+ ### 4.3. Manual wheelhouse workflow
666
813
 
667
814
  The existing manual workflow remains available. After preparing a complete workspace on the build machine, copy the whole workspace and run this command from the copied root:
668
815
 
@@ -685,9 +832,9 @@ odt-env [INI] [OPTIONS]
685
832
  If no arguments are specified, `odt-env` treats the current working directory as ROOT and, when `ROOT/odoo-project.ini` exists,
686
833
  regenerates the workspace artifacts without syncing repositories or recreating the virtual environment.
687
834
 
688
- ### Positional arguments
835
+ ### Project definition (`INI`)
689
836
 
690
- - `INI` — project definition file. It can be:
837
+ `INI` is the optional project definition source used by `odt-env`. It can be:
691
838
 
692
839
  - a local filesystem path, for example:
693
840
 
@@ -788,11 +935,11 @@ Maintenance:
788
935
 
789
936
  - `--create-bundle [BUNDLE]` — create a verified portable ZIP containing Odoo sources, configured addon sources, a sanitized `odoo-project.ini`, and `ROOT/wheelhouse/`. If `BUNDLE` is omitted, the output is `ROOT/dist/ROOT-NAME.odt.zip`. Relative explicit output paths are resolved from the current working directory.
790
937
  - `--allow-dirty-bundle` — allow `--create-bundle` to snapshot Git repositories with uncommitted changes. Without this option, dirty repositories abort bundle creation.
791
- - `--create-from-bundle BUNDLE` — verify and extract a portable bundle into an empty `ROOT`, then recreate `ROOT/venv` using the bundled wheelhouse. This offline deployment path intentionally skips local Docker generation; `--create-docker-deploy` cannot be combined with it.
938
+ - `--create-from-bundle BUNDLE` — verify and extract a portable bundle into an empty `ROOT`, then recreate `ROOT/venv` using the bundled wheelhouse. This offline deployment path intentionally skips Docker workflow generation; `--create-docker-deploy` cannot be combined with it.
792
939
 
793
940
  ### Docker generation
794
941
 
795
- - Local Docker generation is enabled by default. It regenerates `ROOT/docker/local/` and `ROOT/compose.yaml`; addon sources are bind-mounted from the workspace into the Odoo container. Database and filestore backup/restore helpers, including optional restic filestore helpers, are generated under `ROOT/docker/local/scripts/`.
942
+ - Docker workflow generation is enabled by default. It regenerates `ROOT/docker/local/` and `ROOT/compose.yaml`; addon sources are bind-mounted from the workspace into the Odoo container. Database and filestore backup/restore helpers, including optional restic filestore helpers, are generated under `ROOT/docker/local/scripts/`.
796
943
  - `--no-local-docker` — skip regeneration of `ROOT/docker/local/` and `ROOT/compose.yaml`. Existing files are not deleted.
797
944
  - `--create-docker-deploy` — generate a self-contained deployment build context under `ROOT/docker/deploy/`. Addon modules are staged into the context.
798
945
 
@@ -816,7 +963,7 @@ The following sections are supported:
816
963
  - `[virtualenv]` — optional Python and dependency settings
817
964
  - `[odoo]` — required Odoo source settings
818
965
  - `[addons.<name>]` — optional addon sources
819
- - `[docker]` — optional local/deploy Docker generation settings
966
+ - `[docker]` — optional Docker workflow/deploy generation settings
820
967
  - `[config]` — optional Odoo server configuration values
821
968
 
822
969
  ### General rules
@@ -981,109 +1128,3 @@ db_user = odoo
981
1128
  db_password = odoo
982
1129
  http_port = 8069
983
1130
  ```
984
-
985
- ---
986
-
987
- ## Script reference
988
-
989
- This section describes the native helpers under `ROOT/odoo-scripts/`. Local Docker backup/restore helpers are documented in the Local Docker section above.
990
-
991
- Most helper scripts are generated in both Unix (`.sh`) and Windows (`.bat`) variants. `instance.sh` is available only on Unix-like systems.
992
-
993
- Native database backup and restore scripts are generated only when `[config].db_name` is configured.
994
-
995
- The examples below use the Unix form.
996
-
997
- ### run
998
-
999
- Starts Odoo in the foreground.
1000
-
1001
- Any extra arguments are forwarded to the underlying command `odoo-bin`.
1002
-
1003
- Examples:
1004
-
1005
- ```bash
1006
- ./odoo-scripts/run.sh
1007
- ./odoo-scripts/run.sh --dev=all
1008
- ./odoo-scripts/run.sh -i sale,crm --without-demo=all
1009
- ```
1010
-
1011
- ### instance
1012
-
1013
- Manages Odoo as a background service on Unix-like systems.
1014
-
1015
- Logs are written to `ROOT/odoo-logs/odoo-server.log` and the PID is stored in `ROOT/odoo-logs/odoo-server.pid`.
1016
-
1017
- Examples:
1018
-
1019
- ```bash
1020
- ./odoo-scripts/instance.sh start
1021
- ./odoo-scripts/instance.sh stop
1022
- ./odoo-scripts/instance.sh restart
1023
- ./odoo-scripts/instance.sh status
1024
- ```
1025
-
1026
- ### test
1027
-
1028
- Runs Odoo tests.
1029
-
1030
- The script always adds `--test-enable --stop-after-init`.
1031
-
1032
- Any extra arguments are forwarded to the underlying command `odoo-bin`.
1033
-
1034
- Examples:
1035
-
1036
- ```bash
1037
- ./odoo-scripts/test.sh
1038
- ./odoo-scripts/test.sh -i sale --test-tags /sale
1039
- ```
1040
-
1041
- ### shell
1042
-
1043
- Opens an Odoo shell.
1044
-
1045
- Examples:
1046
-
1047
- ```bash
1048
- ./odoo-scripts/shell.sh
1049
- ```
1050
-
1051
- ### backup
1052
-
1053
- Creates a timestamped ZIP backup under `ROOT/odoo-backups/`.
1054
-
1055
- Any extra arguments are forwarded to the underlying command `click-odoo-backupdb` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-backupdb-beta) package.
1056
-
1057
- Examples:
1058
-
1059
- ```bash
1060
- ./odoo-scripts/backup.sh
1061
- ```
1062
-
1063
- ### restore
1064
-
1065
- Restores a backup into the configured database.
1066
-
1067
- The script always adds `--copy --neutralize`.
1068
-
1069
- Any extra arguments are forwarded to the underlying command `click-odoo-restoredb` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-restoredb-beta) package.
1070
-
1071
- Examples:
1072
-
1073
- ```bash
1074
- ./odoo-scripts/restore.sh ./odoo-backups/odoo_20260331_221443.zip
1075
- ./odoo-scripts/restore.sh ./odoo-backups/odoo_20260331_221443.zip --force
1076
- ```
1077
-
1078
- ### update
1079
-
1080
- Updates an Odoo database automatically detecting addons to update based on a hash of their file content.
1081
-
1082
- Any extra arguments are forwarded to the underlying command `click-odoo-update` from [`click-odoo-contrib`](https://pypi.org/project/click-odoo-contrib/#click-odoo-update-stable) package.
1083
-
1084
- Examples:
1085
-
1086
- ```bash
1087
- ./odoo-scripts/update.sh
1088
- ./odoo-scripts/update.sh --update-all
1089
- ```