erplibre/env_var.sh

51 lines
2.1 KiB
Bash
Raw Normal View History

#!/usr/bin/env bash
ERPLIBRE_VERSION=$(cat ".erplibre-semver-version" | xargs)
#EL_USER="erplibre"
EL_USER="${USER}"
#EL_HOME="/${EL_USER}"
EL_HOME="${HOME}"
#EL_HOME_ERPLIBRE="${EL_HOME}/erplibre"
EL_HOME_ERPLIBRE="${PWD}"
EL_HOME_ODOO="${EL_HOME_ERPLIBRE}"/odoo$(cat ".odoo-version" | xargs)/odoo
EL_ODOO_VERSION=$(cat ".odoo-version" | xargs)
EL_POETRY_VERSION=$(cat ".poetry-version" | xargs)
EL_PYTHON_ODOO_VERSION=$(cat ".python-odoo-version" | xargs)
EL_PYTHON_ERPLIBRE_VERSION=$(cat "./conf/python-erplibre-version" | xargs)
EL_ERPLIBRE_VERSION=$(cat ".erplibre-version" | xargs)
[ADD] install: mise as Python provider, pyenv as fallback mise lays down a precompiled CPython where pyenv builds one: seconds against one to three minutes, with no -dev package at all. The choice lives in EL_PYTHON_PROVIDER -- auto, mise or pyenv -- and in a single file, lib_python_provider.sh. The rest of the repository only knows venv paths and needs to know none of this. In auto mode an ALREADY installed interpreter wins, whichever provider put it there. mise is never installed on its own, "curl | sh" commits too much for a script to decide -- make install_mise carries that decision. MISE_PYTHON_COMPILE=false forbids it from quietly compiling: without that guard it would fall back to pyenv's own engine, giving us the slowness without the tooling. That is also what stopped gcc from collapsing while building CPython on a low-memory s390x guest, for nothing. One real bug falls along the way: a failed venv did not stop the install, which then went on and failed further down, far from the cause. --- FR --- mise pose un CPython précompilé là où pyenv en compile un : des secondes contre une à trois minutes, et aucun paquet -dev. Le choix vit dans EL_PYTHON_PROVIDER — auto, mise ou pyenv — et dans un seul fichier, lib_python_provider.sh. Le reste du dépôt ne connaît que des chemins de venv et n'a rien à savoir de tout cela. En mode auto, un interpréteur DÉJÀ posé l'emporte, quel qu'en soit le fournisseur. mise n'est jamais installé de lui-même, « curl | sh » engage trop pour qu'un script en décide — make install_mise porte cette décision. MISE_PYTHON_COMPILE=false lui interdit de compiler en silence : sans ce garde, il retomberait sur le moteur de pyenv, et nous aurions sa lenteur sans son outillage. C'est aussi ce qui a évité que gcc s'écroule en bâtissant CPython sur une VM s390x à faible mémoire, inutilement. Un vrai défaut tombe au passage : un venv raté n'arrêtait pas l'installation, qui continuait et échouait plus loin, loin de la cause. Assisted-by: Claude Opus 5
2026-08-11 22:03:40 -04:00
# Fournisseur d'interpreteur Python : auto | mise | pyenv.
# « auto » prend ce qui est DEJA pose, sinon mise s'il est present (Python
# precompile, quelques secondes), sinon pyenv (compilation). Voir
# script/install/lib_python_provider.sh.
EL_PYTHON_PROVIDER="${EL_PYTHON_PROVIDER:-auto}"
[ADD] install: uv to place Python packages, pip as fallback uv replaces pip where it can: the tools venv and the Poetry bootstrap. The choice lives in EL_PIP_PROVIDER -- auto, uv or pip -- and in a single file, lib_pip_provider.sh, on the exact model of the mise/pyenv switch. A uv failure falls back to pip: it is stricter on metadata and rejects packages pip accepts. Three guards. The target always goes through "--python" rather than being inferred from the active venv: poetry.toml declares a "./.venv" uv would also look for. Python 3.7, still used by Odoo 12 and 13, stays on pip. And "uv pip sync" is never used: it would delete pip itself and everything Poetry laid down. One bug falls along the way: the idempotence guard aimed at .venv.erplibre/bin/poetry while Poetry installs into the Odoo venv, so a successful replay reported failure all the same. --- FR --- uv remplace pip là où il le peut : le venv d'outils et l'amorçage de Poetry. Le choix vit dans EL_PIP_PROVIDER — auto, uv ou pip — et dans un seul fichier, lib_pip_provider.sh, sur le modèle exact de l'aiguillage mise/pyenv. Un échec d'uv retombe sur pip : il est plus strict sur les métadonnées et refuse des paquets que pip accepte. Trois gardes. La cible passe toujours par « --python » plutôt que d'être déduite du venv actif : poetry.toml déclare un « ./.venv » qu'uv chercherait aussi. Python 3.7, encore utilisé par Odoo 12 et 13, reste sur pip. Et « uv pip sync » n'est jamais employé : il supprimerait pip lui-même et tout ce que Poetry a posé. Un défaut tombe au passage : le garde d'idempotence visait .venv.erplibre/bin/poetry alors que Poetry s'installe dans le venv Odoo, si bien qu'un rejeu réussi rapportait quand même un échec. Assisted-by: Claude Opus 5
2026-08-11 23:16:26 -04:00
# Installateur de paquets Python : auto | uv | pip.
# « auto » prend uv s'il est present et si le venv vise est en Python >= 3.8,
# sinon pip ; un echec d'uv retombe sur pip. Voir
# script/install/lib_pip_provider.sh. Note : « poetry install » n'est PAS
# concerne, uv ne lit pas poetry.lock.
EL_PIP_PROVIDER="${EL_PIP_PROVIDER:-auto}"
# The default port where this Odoo instance will run under (provided you use the command -c in the terminal)
# Set to true if you want to install it, false if you don't need it or have it already installed.
EL_INSTALL_WKHTMLTOPDF="True"
# Set the default Odoo port
EL_PORT="8069"
EL_LONGPOLLING_PORT="8072"
# set the superadmin password
EL_SUPERADMIN="admin"
# The configuration systemctl service will be erplibre_dirname
EL_CONFIG="erplibre_${PWD##*/}"
EL_MINIMAL_ADDONS="False"
# Set this to True if you want to install Nginx!
EL_INSTALL_NGINX="False"
# Set the website name
EL_WEBSITE_NAME="localhost"
EL_GITHUB_TOKEN=""
2020-07-06 23:08:05 -04:00
EL_MANIFEST_PROD="./default.xml"
EL_MANIFEST_DEV="./manifest/git_manifest_erplibre.xml"
2026-03-07 02:59:07 -05:00
EL_LANG="fr"
# Verbosité de l'installation (poetry install, repo sync, git daemon).
# 0 = silencieux (défaut), 1 = logs détaillés. On respecte une valeur déjà
# passée en environnement : EL_VERBOSE=1 make install_odoo_18
EL_VERBOSE="${EL_VERBOSE:-0}"