问题

Is that possible to build a self-contained Python virtual environment? By self-contained, I mean that all needed files to execute the program are there, including Python.

I'm using Poetry to manage venvs. Looking at venvs I created using poetry install I see that the dependencies are actually copied, but Python is symlinked.

For example:

>> ls -lah my-venv/bin/
python -> /Users/my-user/.pyenv/versions/3.11.2/bin/python

Also, I tried the virtualenvs.options.always-copy Poetry config, which translates to --always-copy virtualenv configuration, but it didn't copy Python.

Since an expected answer would be "use containers," I say in advance that it's not an option for the given use case.

This question aims to a solution that an "all-in" directory/file can be uploaded to a Linux server and just run without using depending on any system-installed software.

>> ls -lah my-venv/bin/
python -> /Users/my-user/.pyenv/versions/3.11.2/bin/python

答案1

得分: 2

If you want something that does not need a Python interpreter to be preinstalled then: PyInstaller as already mentioned, briefcase also might work, PyOxidizer, or something like Nuitka. I recommend you read this section of documentation "Bringing your own Python executable" as well.

答案2

得分: 1

以下是翻译好的部分：

我找到的最简单的解决方案：
 1. 使用conda/mamba来管理依赖项。它有一个实际安装Python的优势，对于问题用例很有用。
 2. 使用[conda-pack][1]来打包一个`venv`，每个Python用户都知道如何使用。

为什么这种方法解决了问题？因为我们最终得到了一个包含实际二进制文件而不是符号链接的`venv`。所以我们不能只将其共享为`tar.gz`文件，除了项目开发人员之外，**没有人需要学习新技术（每个普通的Python开发人员都可能知道`venv`）。** 它只是工作的：
```bash
# 在源/CI机器上
$ conda pack -n my_env -o my_env.tar.gz

# 在用户/服务器机器上
$ mkdir -p my_env
$ tar -xzf my_env.tar.gz -C my_env
$ source my_env/bin/activate

注意：
我尝试过像PyInstaller和其他人在答案和评论中编写的工具。老实说，它们试图重新发明轮子。例如，PyInstaller递归地查找导入并尝试从发现的导入构建。例如，对于PyArrow的*.pyx依赖项，我的第一次尝试并没有成功。也许我用错了。但是，为什么要重新发明轮子并发现导入，如果我们可以明确地使用主要工具，如标准的venv、Poetry和Conda/Mamba。

<details>
<summary>英文:</summary>

The simplest solution I found:
 1. Use conda/mamba to manage the dependencies. It has the advantage of actually installing Python, which is useful for the question use case.
 2. Use [conda-pack][1] to pack in a `venv` every Python user knows how to use.

Why this approach solves the problem? Because we end up with a `venv` including actual binaries, instead of symblinks. So we can&#39;t just share it as `tar.gz` file and **no one (other than the project developers) has to learn new technologies (every average Python developer is likely to know `venv`).** It just works:
```bash
# ON THE SOURCE/CI MACHINE
$ conda pack -n my_env -o my_env.tar.gz

# ON THE USER/SERVER MACHINE
$ mkdir -p my_env
$ tar -xzf my_env.tar.gz -C my_env
$ source my_env/bin/activate

A note:
I tried using like PyInstaller and other tools people wrote in answers and comments. Honestly, they try to reinvent the wheel. For example, PyInstaller goes recursively over the imports and tries to build from the discovered imports. On my first try it didn't work for PyArrow *.pyx dependencies, for example. Maybe I used it wrong. But, why invent the wheel and discover the imports if we can go explicit with major tools like standard venv, Poetry, and Conda/Mamba.

答案3

得分: 0

你可以使用像PyInstaller这样的工具。根据文档：

PyInstaller将Python应用程序及其所有依赖项捆绑成一个单独的包。用户可以在不安装Python解释器或任何模块的情况下运行打包的应用程序。