Support for the relative path when using own packages

[vladjohnson]

Steps to Reproduce

rye add local_package ./local_package -- assuming that the local package is located in the project folder.

Expected Result

The expected result for the relative path would be ./local_package instead of /home/user/package/local_package, which is what Rye currently has.

Actual Result

localpackage @ /home/user/package/local_package within pyproject.toml.

I have attempted to resolve this issue by using PROJECT_ROOT, but I am getting a UV error stating that PROJECT_ROOT environmental variable was not found. Please help me figure out a solution. Thank you!

Version Info

0.37.0

Stacktrace

No response

[bluss]

Some workarounds are written down in issue #912

• The current design - even if there are bugs like #912 - is that Rye projects that use pdm as build system should support relative paths, while those that use hatchling (default) should not. The reason is among other things that Rye supports (supported) adding relative paths in a syntax that pdm agrees with, but does not interoperate with Hatch's relative paths.
• Rye's design prefers using its workspace support instead of relative path dependencies, this should also work.

[vladjohnson]

Hey @bluss thanks for the help. Can you please help me understand how to use local packages through Rye workspaces? A simple example would be highly appreciated. Thanks!

[bluss]

Sure.

Workspace docs

I used rye init (twice) and some editing to create this

workspace
├── local_package
│   ├── pyproject.toml
│   ├── README.md
│   └── src
│       └── local_package
│           └── __init__.py
├── pyproject.toml
├── README.md
├── requirements-dev.lock
├── requirements.lock
└── src
    └── workspace
        └── __init__.py

workspace/pyproject.toml looks like this (this is the project root). The [tool.rye.workspace] is the important part. I also edited in the dependency under dependencies. I don't know a way to add the inter-workspace dependency using "rye add" but that could be my knowledge having some holes.

[project]
name = "workspace"
version = "0.1.0"
description = "Add your description here"
authors = []
dependencies = [
    "local_package",
]
readme = "README.md"
requires-python = ">= 3.8"

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.rye]
managed = true
dev-dependencies = []

[tool.hatch.metadata]
allow-direct-references = true

[tool.hatch.build.targets.wheel]
packages = ["src/workspace"]

[tool.rye.workspace]
members = ["local_package"]

Use rye show to ask rye about your project, so then you can check what it thinks about your workspace:

> rye show
project: workspace
path: /home/user/workspace
venv: /home/user/workspace/.venv
target python: 3.8
venv python: cpython@3.12.3
virtual: false
workspace: /home/user/workspace
  members:
    workspace (./)
    local_package (./local_package)
configured sources:
  default (index: https://pypi.org/simple/)

[vladjohnson]

Fantastic. Thank you so much for providing the example. How would I go about building the core package with the dependencies included? I assume that's handled automatically in the background. Thanks

[bluss]

rye sync sets up the workspace as usual, with all members included. If "build" means building wheels, then I have no idea :slightly_smiling_face:.

[vladjohnson]

Thanks! Good to know

[spinda]

Unfortunately the given workaround simply doesn't work. Rye seems to ignore tool.rye.workspace entirely; or at least, it doesn't bother looking for any members, no matter what I put into the members key.

$ rye show
project: workspace
path: /home/spinda/workbench/temp/wtf-rye
venv: /home/spinda/workbench/temp/wtf-rye/.venv
target python: 3.8
venv python: cpython@3.8.19
virtual: false
workspace: /home/spinda/workbench/temp/wtf-rye
  members:
    workspace (./)
configured sources:
  default (index: https://pypi.org/simple/)

$ rye --version
rye 0.39.0
commit: 0.39.0 (bf3ccf818 2024-08-21)
platform: linux (x86_64)
self-python: cpython@3.12.3
symlink support: true
uv enabled: true