Emballer une application Python et son environnement sur MS Windows pour une utilisation par d'autres utilisateurs, la rendant "prête à fonctionner" sur n'importe quelle machine, est une tâche délicate. Cet article de blog décrit ma solution personnelle : quelque chose que j'appelle Python pour Windows Bundle, qui est similaire à un environnement virtuel mais est portable entre machines.
Le Python Bundle se situe quelque peu à l'intersection de la valeur et des compromis offerts par les environnements virtuels, les installations Python régulières et les exécutables autonomes créés par des outils comme PyInstaller ou Py2exe.
Aucun nouvel outil n'est requis pour créer un tel Bundle. Il s'agit simplement d'une convention souple et légère pour la structure des dossiers et de certains scripts wrapper que vous pouvez facilement créer manuellement. Ou automatisez leur création dans des scripts ou des tâches CI.
Supposons que nous souhaitons empaqueter et fournir une application ou un environnement Python à nos utilisateurs de manière autonome et « prête à l'emploi ».
Nous ne savons peut-être pas quelle version de Python nos utilisateurs ont installée, ou il se peut qu'elle ne soit pas installée du tout. Nous ne voulons certainement pas altérer une installation Python qu'ils possèdent peut-être déjà, ce qui implique de ne pas les laisser demander l'installation de versions Python supplémentaires. En d’autres termes : nos packages doivent contenir tout ce dont nos utilisateurs ont besoin pour exécuter nos applications ou utiliser notre environnement Python.
Après quelques réflexions, nous pourrions penser à créer un environnement virtuel (python -m venv venv_dir), à tout installer dans l'environnement virtuel, puis à compresser et distribuer le dossier de l'environnement virtuel à nos utilisateurs. Cependant, nous réalisons que le dossier de l'environnement virtuel ne peut pas être facilement déplacé vers un chemin différent de celui où il a été créé. De plus, notre environnement virtuel s'appuie sur l'installation de base de Python utilisée pour le créer (en utilisant exactement la même version de Python dans ce chemin). Par conséquent, nous devons indiquer à nos utilisateurs où placer leurs copies de l’environnement virtuel. Et ils doivent installer une version spécifique de Python dans un chemin spécifique. Ce n'est pas ce que nous voulons.
Au lieu d'un environnement virtuel, nous pouvons installer toutes nos exigences dans une installation Python standard, puis compresser et distribuer son dossier (par exemple c:Program FilesPython 3.13.1). Cela en grande partie fonctionne. Le répertoire d'installation de Python sous Windows peut généralement être déplacé vers un chemin différent (ce n'est pas le cas sous Unix en raison des chemins de préfixes statiques - mais c'est un autre sujet).
Il y a cependant un gros défaut : il existe un exécutable de script (fichier .exe dans le répertoire .Scripts, généralement créé par pip lorsque le package n'est pas qu'une bibliothèque mais fournit également un script comme point d'entrée. Un tel exécutable Le fichier est pip.exe lui-même). Ces exécutables de script s'appuient sur le chemin d'installation de Python qui est codé en dur « lui-même ».
Des outils comme PyInstaller ou Py2exe peuvent regrouper une application Python et toutes ses dépendances dans un seul package. Les utilisateurs n'ont pas besoin d'installer un interpréteur Python ou des modules pour exécuter des applications packagées.
Cela a parfaitement répondu à nos besoins de distribution. Cependant, le compromis est que nous ne distribuons pas un environnement Python complet, mais un format Bundle personnalisé et simplifié. Cela pourrait être le bon outil pour empaqueter votre application. Cependant, cela ne s'applique pas si nous souhaitons par exemple envoyer à nos utilisateurs un environnement Python "starter kit" qui peut être utilisé dans un IDE et étendu avec des installations pip supplémentaires, etc. Nous recherchons une solution plus générale.
Nous allons commencer dans Powershell en créant un dossier pour notre Bundle :
<code>mkdir bundle cd bundle</code>
Ensuite, nous ajouterons une installation Python dans
<code>curl.exe -L "https://www.nuget.org/api/v2/package/python/3.13.1" -o python3.zip Expand-Archive .\python3.zip -DestinationPath extracted_nuget move .\extracted_nuget\tools python3 rm -R extracted_nuget rm -R .\python3.zip</code>
Maintenant, notre Bundle ressemble à ceci :
<code>bundle └───python3 ├───python3.exe ├───Lib/ ├───...</code>
Ajoutons également un répertoire Scripts :
<code>mkdir python3\Scripts</code>
Nous n’avons pas encore activé pip, alors faisons-le maintenant.
<code>python3\python.exe -m ensurepip</code>
Pour résoudre le problème de la création par pip de fichiers .exe dans le répertoire Scripts qui s'appuient sur des chemins d'installation Python codés en dur, nous utiliserons un script wrapper pour pip qui corrige le comportement de pip.
Créons un fichier
<code>#!/usr/bin/python import sys import os if __name__ == "__main__": from pip._vendor.distlib.scripts import ScriptMaker ScriptMaker.executable = r"python.exe" from pip._internal.cli.main import main sys.exit(main())</code>
Comment ça marche ? Chaque fois que nous installons un package via notre script wrapper (par exemple, python3python.exe pip_wrapperscriptspip.py
Bien sûr, il y a des risques et des conséquences. Maintenant, notre travail consiste à nous assurer que lorsque quelqu'un exécute un tel fichier Scripts*.exe « corrigé », le bon python.exe se trouve dans la variable PATH. C'est pourquoi notre Bundle doit être activé par l'utilisateur, à l'instar d'un environnement virtuel. Nous en discuterons plus tard.
(Voir ici pour plus d'informations sur cette idée de pip wrapper)
Maintenant, ne serait-il pas bien si nous avions également un pip.exe pour notre wrapper pip ? De cette façon, nous pourrons simplement utiliser les commandes pip à l'avenir (et ne pas avoir à utiliser python pip.py) ? Créons-en un. Bien entendu, il doit également être portable, c'est pourquoi nous le créerons de la même manière.
Pour cela, créons un dossier
<code>mkdir bundle cd bundle</code>
Ensuite, utilisons python3python.exe pour démarrer un shell Python (REPL) et exécuter le code suivant pour créer pip.exe.
<code>curl.exe -L "https://www.nuget.org/api/v2/package/python/3.13.1" -o python3.zip Expand-Archive .\python3.zip -DestinationPath extracted_nuget move .\extracted_nuget\tools python3 rm -R extracted_nuget rm -R .\python3.zip</code>
Notre structure de dossiers doit maintenant être affichée comme suit:
<code>bundle └───python3 ├───python3.exe ├───Lib/ ├───...</code>
**Bundle** | **虚拟环境** | **Python安装** | **Pyinstaller** | |
**路径独立(可以复制到文件系统中的任何路径)?** | 是 | 否 (Python安装路径硬编码在虚拟环境中) | 否 (.\scripts\*.exe文件将中断) | 是 |
**可以在同一系统上有多个实例** | 是 | 是 | 没有问题 (概念是一个Python版本每个用户或系统一个Python安装) | 是 |
**磁盘使用情况** | 大 (包含完整的Python安装) | 小 (依赖于Python安装) | 大 | 中等 |
**需要激活** | 是 | 是 | 否 | 否 |
**单个可执行文件** | 否 | 否 | 否 | 是 |
**可以用作常规Python安装(REPL、pip、脚本等)** | 是 | 是 | 是 | 否 |
**可以与IDE一起使用?** | 是,但您可能需要在IDE的运行/调试配置文件中配置环境变量 | 是 | 是 | 否 |
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!