Skip to content

FAQ

This section should cover some commonly asked questions. If you do not find an answer here, consider reaching out to the community.

How Do I Install PyTorch?

PyTorch requires setting up manual sources as it's not installed via PyPI. These sources can be set up in pyproject.toml for a simple project or globally in the config.

  • Option 1: pyproject.toml

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

  • Option 2: ~/.rye/config.toml

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

Afterwards you can add pytorch as you would expect:

rye add torch torchvision torchaudio

Windows Developer Mode

Rye does not require symlinks but it works significantly better with them. On Windows support for symlinks is restricted to privileged accounts. The reason for this is that Symlinks were a late addition to Windows and some applications are not developed with them in mind which can cause misbehavior or in the worst case security issues in those applications. Symlinks support however is enabled when the "developer mode" is activated on modern Windows versions.

Enabling "developer mode" has changed in later version of Windows. For older versions:

  1. Press Win+I to open the settings
  2. In the settings dialog click on "Privacy & security"
  3. In the "Security" section click on "For developers"
  4. Enable the toggle "Developer Mode"
  5. In the "Use developer features" dialog confirm by clicking "Yes".

In more modern versions:

  1. Press Win+I to open the settings
  2. In the settings dialog click on "System"
  3. In the "System" section click on "For developers"
  4. Enable the toggle "Developer Mode"
  5. In the "Use developer features" dialog confirm by clicking "Yes".
What happens if I don't enable it?

Enabling symlinks is not strictly required as Rye automatically falls back to hardlinks and junction points. However not having symlinks enabled will ultimately result in a worse user experience for the following reasons:

  • Custom toolchain registration uses proxy files rather than actual symlinks which means that the executables in the .rye\py path are non executable.
  • All shims will be installed as hardlinks. This can cause issues when upgrading Rye while Python is in use. These hardlinks will also continue to point to older Rye executables creating more hard drive usage.
  • Virtualenvs will be created with copies rather than symlinks.
  • Junction points are used where symlinks to directories are otherwise used. Some tools might accidentally not detect junction points which can cause deletion of virtualenvs to accidentally also delete or destroy the toolchain behind it.

Missing Shared Libraries on Linux

The Python builds that Rye uses require a Linux installation compatible to the Linux Standard Base Core Specification (LSB). Unfortunately not all Linux distributions are strictly adhering to that specification out of the box. In particularly the library libcrypt.so.1 is commonly not installed on certain Linux distributions but the _crypt standard library module depends on it. Depending on the Linux distributions you need to run different commands to resolve this:

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

There have also been reports of an error being generated at installation time despite libcrypt.so.1 being installed when a different ldd (eg: Homebrew) shadows the system one. In that case try the installation again after giving the default one higher priority in the `PATH:

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

References to Build-Time Paths

The prefers using standalone Python builds. As Python historically is not much accommodating to portable builds there are various limitations still with this approach. One of them is that built Python distributions capture some absolute paths and other build-time configuration. These file paths are then often used by build tools to invoke C compilers. For instance you might run into a compiler error like error: stdio.h: No such file or directory when building C extensions. There is no known solution to this problem today other than registering a non portable toolchain.

This issue is inherited from python-build-standalone and more information can be found in the documentation: References to Build-Time Paths. There is also an open Rye issue for it: Issue #621.

TKinter Support

TKinter uses TCL behind the scenes. Unfortunately this also means that some runtime support is required. This runtime support is provided by the portable Python builds, however the way TCL is initialized on macOS and Linux won't find these files in virtualenvs. Newer versions of Rye will automatically export the TCL_LIBRARY and TK_LIBRARY environment variables for you in a manner very similar to this:

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 Interactive Prompt Input Messed Up

The Python builds that Rye uses are compiled against libedit rather than readline for licensing reasons. You might run into unicode issues on input as a result of this due to limitations in libedit. In some cases though you might also discover that the backspace key does not work or arrow keys don't work as expected. This can be because the terminfo database cannot be found.

For solutions to this issue, read the behavior quirks guide in the Standalone Python Builds documentation for solutions.

Can I use Rye Alongside Other Python Installations?

Rye given it's experimental nature does not want to disrupt already existing Python workflows. As such using it alongside other Python installations is intentionally supported. Even if the Rye shims come first on the PATH, Rye will automatically resolve to a different Python installation on the search path when invoked in a folder that contains a non Rye managed project.

As such the answer is a clear yes!

Musl/Alpine Support

When bootstrapping it can happen that you are running into a confusing error like "No such file or directory (os error 2)". This can happen on MUSL based Linux systems like Alpine. The reason for this is that Rye downloads distribution independent Python interpreters which are not compatible with Linux systems that do not use glibc. The solution today is to install Python via other means and to install Rye with a custom RYE_TOOLCHAIN. For more information see Customized Installation

Wheels Appear to be Missing Files

You might be encountering missing files in wheels when running rye build and you are using hatchling. The reason for this is that rye build uses "build" behind the scenes to build wheels. There are two build modes and in some cases the wheel is first built from an sdist. So if your sdists does not include the necessary data files, the resulting wheel will also be incorrect.

This can be corrected by adding the files to the include in the hatch config for sdists. For instance the following lines added to pyproject.toml will add the data files in my_package and all the tests to the sdist from which the wheel is built:

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

Can I Relocate Virtualenvs?

Rye very intentionally places the virtualenv (.venv) in the root folder of the workspace. Relocations of virtualenvs is not supported. This is a very intentional decision so that tools do not need to deal with various complex alternatives and can rely on a simple algorithm to locate it. This is a form of convention over configuration and can also assist editor integrations.

There are some known downsides of this. For instance if you are placing your projects in Dropbox, it would cause this folder to synchronize. As a way to combat this, Rye will automatically mark the virtualenv with the necessary flags to disable cloud sync of known supported cloud synchronization systems.

For override this behavior you can set the behavior.venv-mark-sync-ignore configuration key to false.

Why Does Rye Contain Trojan "Bearfoos"?

Unfortunately Windows likes to complain that Rye contains the trojan "Win32/Bearfoos.A!ml". This seems to be something that happens to a few programs written in Rust every once in a while because the compiler spits out some bytes that have been associated with Trojans written in Rust.

It can be ignored. For more information see the discussion Windows Bearfoos virus associated with rye.