erplibre/env_var.sh

84 lines
4 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}"
# NixOS : donner aux roues manylinux les bibliotheques que nix-ld declare.
#
# nix-ld fournit l'editeur de liens (/lib64/ld-linux-x86-64.so.2) aux binaires
# etrangers qu'il LANCE. Mais un « .so » de roue manylinux n'est pas lance :
# il est charge par dlopen depuis le CPython du systeme, qui est un binaire de
# Nix et ne lit pas NIX_LD_LIBRARY_PATH. Sans cette ligne, l'installation
# reussit et « import psycopg2 » echoue APRES, sur « libz.so.1: cannot open
# shared object file » -- une erreur qui ne parle ni de pip ni de Nix.
#
# Rien ailleurs : la variable n'est posee que la ou nix-ld existe, et ne
# masque donc aucune bibliotheque sur les autres systemes.
if [ -n "${NIX_LD_LIBRARY_PATH:-}" ]; then
export LD_LIBRARY_PATH="${NIX_LD_LIBRARY_PATH}${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}"
fi
# NixOS : les chemins de compilation, relus du SYSTEME DE FICHIERS.
#
# Le module declare CPATH, LIBRARY_PATH et PKG_CONFIG_PATH, mais une session
# les recoit de pam_env a son OUVERTURE. Or l'installation applique le module
# (« make install_os ») puis compile (« make install_odoo_18 ») dans la MEME
# session : la sienne est plus vieille que ce qu'elle vient de declarer. Les
# trois paquets du verrou qui n'ont pas de roue amont s'arretaient alors sur
# « lber.h », « cups/http.h » et « mysql.h » -- au PREMIER passage seulement,
# ce qui est la pire des pannes : le second reussit et donne raison a tort.
#
# « /run/current-system/sw » est le profil courant du systeme, un lien que le
# rebuild vient de reposer : le lire ne depend d'aucune variable heritee.
if [ -d /run/current-system/sw ]; then
export CPATH="/run/current-system/sw/include${CPATH:+:${CPATH}}"
export LIBRARY_PATH="/run/current-system/sw/lib${LIBRARY_PATH:+:${LIBRARY_PATH}}"
export PKG_CONFIG_PATH="/run/current-system/sw/lib/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}"
fi