Provide a way to add local packages as editable

[ma-sadeghi]

Currently, there seems to be no way of adding local dependencies as editable. I thought rye add package --path path/to/package installs package in editable mode, but apparently not. This is super helpful (crucial) when developing multiple packages that (might) depend on each other. For more context: I've only tried in a virtual project, not a workspace.

[mitsuhiko]

There is today with workspaces. There is not for packages contained outside of a workspace. Basically every member of a workspace is editable out of the box. But I agree that editable installs for other packages would be nice to have too.

[ma-sadeghi]

I'll give it a try. I noticed workspaces in the documentation, but thought that virtual packages and workspaces are mutually exclusive. IIUC based on your comment, they are not, is that so? (I made a virtual project rather than a workspace because the documentation advised that if the top level package shouldn't be importable, then opt for virtual projects)

[bluss]

@ma-sadeghi you can combine, I was thinking maybe rye can show how to do that, #857, feels the most natural?

[mitsuhiko]

The issue with editable installs from other locations is that it's not entirely clear where that information should be stored. Probably not in pyproject.toml. Maybe a .rye/links or something?

[ma-sadeghi]

I think so, because I'd like to commit the project.toml file to git history, which would make it not universal

[ssteinerx]

I'm trying to get editable installs using a workspace, but not all of the dependencies are in the current directory tree.

Unfortunately, creating symlinks to those directories, then attempting to use those symlinks in the workspace's members list silently fails to install the symlinked module, editable or not.

Copying the files into a subdirectory works fine, and it is installed editable.

It would seem to me that supporting symlinks within a workspace's members list would solve some of these issues. I'd be happy to file a separate issue if that'd help.

[bnorick]

I think a feature like this is needed, but I am not sure about the best approach.

In a monorepo I am working on, there is the following structure:

monorepo
  project0
  project1 ← project0
  project2 ← project0

Each project should be usable independently and their dependencies may conflict (so a top level workspace does not apply). I would like for users of the repo to be able to rye sync in monorepo/project1 when they need to work on that project and have an editable install of monorepo/project0.

Above I only showed a single dependencies per project, but in the future there may be more than one dependency from the monorepo for a given project, e.g., project4:

monorepo
  project0
  project1 ← project0
  project2 ← project0
  project3
  project4 ← project0, project3

One approach I considered is allowing each project to have a workspace definition which is aware not only of sub-projects in its own directory but also of sibling projects in its parent project(s). That seems like the most natural approach to this problem and just requires that projects which are part of a virtual project also search for pyproject.toml files with an expanded scope (any parent projects, or possibly only explicitly specified parent projects). Maybe not hard to implement, though I haven't tried developing on rye yet.

[emorikawa]

I have a similar problem to @bnorick. I tried for as long as possible to keep a monorepo workspace working. However, for me Project A is a super heavy bloated thing, Project B depends all kinds of awful old scientific python code that doesn't place nicely with rye or uv at all, and Project C through Project J are all modern, happy Rye packages.

Being able to keep my projects isolated is currently much nicer than having The One Workspace Requirements Set to Rule Them All. It's simply not possible because of my Project B and can't arrive at a unified dependency set because of Project A

The problem is that Project C depends on Project D. There's no way to co-develop these right now.

This singular issue has me moved back to pyenv right now.

My natural inclination is to just have rye add package --path path/to/package (or better yet just detect it's a local path without the --path) automatically be editable.

My workaround right now is, on every single update:

# from within monorepo/package-c
rye remove package-d && rye add package-d --path ../package-d