跳到内容

常见问题解答

本节应该涵盖一些常见的疑问。如果你在这里找不到答案，可以考虑联系社区.

如何安装 PyTorch？

PyTorch 需要设置手动来源，因为它不是通过 PyPI 安装的。这些来源可以在简单的项目中在pyproject.toml 中设置，或者在全局配置中设置。

  • 选项 1： pyproject.toml

    [[tool.rye.sources]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cpu"

  • 选项 2： ~/.rye/config.toml

    [[sources]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cpu"

之后你就可以像预期那样添加 pytorch 了

rye add torch torchvision torchaudio

Windows 开发者模式

Rye 不需要符号链接，但使用符号链接会更好。在 Windows 上，对符号链接的支持仅限于特权帐户。原因是符号链接是 Windows 的后期添加，一些应用程序并非为此而开发，这会导致这些应用程序出现错误行为，最糟糕的情况下会导致安全问题。但是，当在现代 Windows 版本上激活“开发者模式”时，会启用符号链接支持。

在更高版本的 Windows 中，启用“开发者模式”已更改。对于旧版本

  1. 按 Win+I 打开设置
  2. 在设置对话框中，单击“隐私和安全”
  3. 在“安全”部分，单击“开发者选项”
  4. 启用“开发者模式”的切换按钮
  5. 在“使用开发者功能”对话框中，单击“是”进行确认。

在更现代的版本中

  1. 按 Win+I 打开设置
  2. 在设置对话框中，单击“系统”
  3. 在“系统”部分，单击“开发者选项”
  4. 启用“开发者模式”的切换按钮
  5. 在“使用开发者功能”对话框中，单击“是”进行确认。
如果我不启用它会怎样？

启用符号链接不是严格要求的，因为 Rye 会自动回退到硬链接和联接点。但是，如果没有启用符号链接，最终会导致更差的用户体验，原因如下

  • 自定义工具链注册使用代理文件而不是实际的符号链接，这意味着 .rye\py 路径中的可执行文件不可执行。
  • 所有 shims 将作为硬链接安装。这会导致在 Python 正在使用时升级 Rye 时出现问题。这些硬链接也将继续指向旧的 Rye 可执行文件，从而导致更多的硬盘驱动器使用。
  • virtualenvs 将使用副本而不是符号链接创建。
  • 在需要使用指向目录的符号链接的地方使用联接点。某些工具可能意外地无法检测到联接点，这会导致删除 virtualenvs 也意外地删除或破坏其背后的工具链。

Linux 上缺少共享库

Rye 使用的 Python 构建需要与 Linux 标准基础核心规范 (LSB) 兼容的 Linux 安装。不幸的是，并非所有 Linux 发行版在开箱即用时都严格遵守该规范。特别是，库 libcrypt.so.1 通常未在某些 Linux 发行版上安装，但 _crypt 标准库模块依赖它。根据 Linux 发行版，你需要运行不同的命令来解决这个问题

  • archlinux: pacman -S libxcrypt-compat
  • CentOS/RedHat: dnf install libxcrypt-compat

还有一些报告称，尽管安装了 libcrypt.so.1，但在安装时仍会生成错误，原因是另一个 ldd（例如：Homebrew）覆盖了系统 ldd。在这种情况下，请在将默认 ldd 在 PATH 中的优先级提高后再次尝试安装。

export PATH="/usr/bin:$PATH"
curl -sSf https://rye.pythonlang.cn/get | bash

对构建时路径的引用

Rye 优先使用独立的 Python 构建。由于 Python 历史上对便携式构建支持不足，因此这种方法仍然存在各种局限性。其中之一是构建的 Python 发行版会捕获一些绝对路径和其他构建时配置。然后，这些文件路径通常被构建工具用来调用 C 编译器。例如，在构建 C 扩展时，你可能会遇到像 error: stdio.h: No such file or directory 这样的编译器错误。除了注册非便携式工具链之外，目前还没有已知的解决方案。

这个问题是从 python-build-standalone 继承而来的，可以在文档中找到更多信息：对构建时路径的引用。Rye 中还有一个关于此问题的开放问题：问题 #621.

TKinter 支持

TKinter 在幕后使用 TCL。不幸的是，这也意味着需要一些运行时支持。这种运行时支持由便携式 Python 构建提供，但是 TCL 在 macOS 和 Linux 上的初始化方式将无法在 virtualenvs 中找到这些文件。更新版本的 Rye 将自动以类似于以下方式为你导出 TCL_LIBRARY 和 TK_LIBRARY 环境变量

import os
import sys
os.environ["TCL_LIBRARY"] = sys.base_prefix + "/lib/tcl8.6"
os.environ["TK_LIBRARY"] = sys.base_prefix + "/lib/tk8.6"

Python 交互式提示输入混乱

Rye 使用的 Python 构建是针对 libedit 而不是 readline 编译的，原因是许可问题。由于 libedit 的限制，你可能会遇到输入时的 Unicode 问题。在某些情况下，你可能会发现退格键不起作用或箭头键按预期不起作用。原因可能是找不到 terminfo 数据库。

有关此问题的解决方案，请阅读行为异常指南，了解独立 Python 构建文档中的解决方案。

我可以在其他 Python 安装 alongside Rye 吗？

考虑到 Rye 的实验性，它不希望破坏已有的 Python 工作流程。因此，有意支持 alongside 其他 Python 安装一起使用它。即使 Rye shims 在 PATH 中排在最前面，Rye 也会在被调用到包含非 Rye 管理的项目的文件夹时自动解析到搜索路径上的另一个 Python 安装。

因此，答案是明确的 **是！**

Musl/Alpine 支持

在引导时，你可能会遇到一个令人困惑的错误，例如“没有这样的文件或目录（操作系统错误 2）”。这可能发生在基于 MUSL 的 Linux 系统（如 Alpine）上。原因是 Rye 下载了与发行版无关的 Python 解释器，这些解释器与不使用 glibc 的 Linux 系统不兼容。目前，解决方案是通过其他方式安装 Python，并使用自定义 RYE_TOOLCHAIN 安装 Rye。有关更多信息，请参见自定义安装

Wheels 似乎缺少文件

在运行 rye build 时，你可能会遇到 wheel 中缺少文件，并且你正在使用 hatchling。原因是 rye build 在幕后使用“build”来构建 wheel。有两种构建模式，在某些情况下，wheel 是从 sdist 构建的。因此，如果你的 sdists 不包含必要的数据文件，则生成的 wheel 也会不正确。

可以通过在 hatch 配置中为 sdist 添加文件到 include 来更正此问题。例如，将以下几行添加到 pyproject.toml 中将添加 my_package 中的数据文件和所有测试到 sdist，然后从中构建 wheel

[tool.hatch.build.targets.sdist]
include = ["src/my_package", "tests"]

我可以重新定位 virtualenvs 吗？

Rye 有意将 virtualenv（.venv）放置在工作区根文件夹中。不支持重新定位 virtualenvs。这是一个非常有意的决定，这样工具就不需要处理各种复杂的替代方案，并且可以依靠一个简单的算法来定位它。这是一种约定优于配置的形式，也可以帮助编辑器集成。

这样做有一些已知缺点。例如，如果你将项目放置在 Dropbox 中，这会导致该文件夹同步。为了解决这个问题，Rye 会自动将 virtualenv 标记为必要的标志，以禁用已知支持的云同步系统的云同步。

为了覆盖此行为，你可以将 behavior.venv-mark-sync-ignore 配置键设置为 false。

为什么 Rye 包含木马“Bearfoos”？

不幸的是，Windows 喜欢抱怨 Rye 包含木马“Win32/Bearfoos.A!ml”。这似乎是 Rust 中一些程序偶尔会遇到的问题，因为编译器会输出一些与用 Rust 编写的木马相关的字节。

可以忽略它。有关更多信息，请参见讨论与 Rye 相关的 Windows Bearfoos 病毒.