Rye init error for projects outside the defined workspace

[Haskely]

I'm experiencing an issue with Rye when trying to manage environments for projects that are not part of a workspace. My project structure includes two examples within the examples folder. The first example, example_1, relies on the main project and is correctly set up within the workspace in pyproject.toml:

# my_project/pyproject.toml
[tool.rye.workspace]
members = ["examples/example_1"]

Running rye init within my_project/examples/example_1/ works as expected.
However, the second example, example_2, does not depend on the main project, and I intended to use Rye for its environment management separately. Despite successfully running rye init in my_project/examples/example_2/, attempting to synchronize the environment with rye sync results in an error:

error: project /Users/nova/rye_test/examples/example_2/pyproject.toml is not part of pyproject workspace /Users/nova/rye_test

This error suggests that Rye requires all projects to be included in a workspace, which seems to be an unnecessary constraint. As a workaround, I had to resort to the traditional python -m venv approach to manage example_2's environment.
Is there a way to use Rye for projects that are not listed in the workspace, or is this a limitation of the current implementation?

[ma-sadeghi]

Indeed, given that members is explicitly defined for workspaces, it'd be great if we could still use rye for projects that happen to be in the workspace root folder, but are not a member.

One might ask why the other project "happens" to be within the workspace's root folder, which is a valid question. In my case, I use (virtual) workspaces as a drop-in replacement for a global conda virtual env that I used to use for most of my projects. If we could optionally place workspaces in some agreed-upon location, e.g., ~/.rye/workspaces, and lift the requirement that members must be within the workspace's root folder, I feel like this issue would automatically be addressed.

[ferrants]

If you add the following to the nested project's pyproject.toml, it gets around this issue:

[tool.rye.workspace]
members = []

Determined this behavior by looking at this:

rye/rye/src/pyproject.rs

Line 626 in 10d691d

"project {} is not part of pyproject workspace {}",

rye/rye/src/pyproject.rs

Lines 381 to 398 in 10d691d

	fn try_load_from_toml(doc: &DocumentMut, path: &Path) -> Option<Workspace> {
	doc.get("tool")
	.and_then(|x| x.get("rye"))
	.and_then(|x| x.get("workspace"))
	.and_then(|x| x.as_table_like())
	.map(|workspace| Workspace {
	root: path.to_path_buf(),
	doc: doc.clone(),
	members: workspace
	.get("members")
	.and_then(|x| x.as_array())
	.map(|x| {
	x.iter()
	.filter_map(|item| item.as_str().map(|x| x.to_string()))
	.collect::<Vec<_>>()
	}),
	})
	}