-
-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support workspace only project #309
Conversation
.and_then(|x| x.get("rye")) | ||
.and_then(|x| x.get("workspace-only")) | ||
.and_then(|x| x.as_bool()) | ||
.unwrap_or(false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would this config variable live better inside the existing group called tool.rye.workspace
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about instead of adding a workspace only value we just expect members = [] where members is empty? So it's implied to be used as a workspace without members to install.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess there are different ways to go but I was thinking that a workspace-only can be used both with members and without. And it would always be a workspace, hence the workspace key should be set anyway.
(Edit, I guess to clarify, in my model the "only" does not mean there are no members. It means the project is only a workspace and not a python package. And a workspace can always have members in it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tool.rye.workspace
configuration is not normally needed for single project development. The workspace-only
here might be more appropriately called no-package
? or is-package = true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting tool.rye.workspace
makes sure that rye creates the virtualenv in that (the current) project's directory, which fits well with the "workspace-only" feature.
Do we need an additional orthogonal marker that's independent of workspace? Then you create more scenarios and additional complexity (package or "not package", workspace or not workspace is a 2x2 matrix). We can have three combinations, where a pyproject.toml becomes with rye, a:
- python package
- python package and a workspace
- workspace (only)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To just keep the discussion diverse, I kinda think about this as everything is a workspace. Some workspaces you want to add packages/projects (members) to. Some of those projects/packages (members) are meant to be installed or their environments are managed via a workspace .venv.
So
- python package
What keeps us from considering it as
- python package and a workspace
and
- workspace (only)
Is just a workspace with no added members.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate that. A workspace is a ceiling, or the top level of a thing. Can't include workspaces in workspaces. Then it would seem anything that is "the top" is a workspace?
let applicable_extras = | ||
format_project_extras(features_by_project.as_ref(), &pyproject)?; | ||
writeln!(local_req_file, "-e {}{}", rel_url, applicable_extras)?; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this skips installing any workspace member, but it's only the root we want to skip installing (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes indeed, further consideration is needed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw I think your PR did something useful when I tried it, I inserted the skip root (but keep other members) here and a name in the pyproject file, and then rye sync did what was expected I think - pulling in members and dev-dependencies. Since this is all close to the pip-tools backend (which might be replaced), I think it's tricky to know how to approach this change. (I mean: whatever we implement might need to be changed later?)
Using /o
/pyproject.toml
/src/o
/o1
/pyproject.toml
/src/o1
/o2
/pyproject.toml
/src/o2 Each project can declare whether it is |
e36a33c
to
901bea3
Compare
901bea3
to
e9c5722
Compare
@ischaojie it does seem to fit together well using project only. When you say for example o2 is a project only, what is that used for? Wondering about the usecase for having a leaf that's not a python lib. |
some team use monorepo |
Thanks to all of discussions, here is what's I take:
My expectation from Rye:
Currently
pyproject.toml[project]
name = "xyz"
version = "0.1.0"
description = "Add a short description here"
authors = [
{ name = "Tester", email = "Tester@test.com" }
]
dependencies = []
readme = "README.md"
requires-python = ">= 3.7"
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
[tool.rye]
managed = true
[tool.hatch.metadata]
allow-direct-references = true This is a workspace that manages one package. IIUC what's this PR tries to do is prevent create a workspace that limited to any packages.
pyproject.toml[project]
name = "xyz"
version = "0.1.0"
description = "Add a short description here"
authors = [
{ name = "Tester", email = "Tester@test.com" }
]
dependencies = []
readme = "README.md"
requires-python = ">= 3.7"
[tool.rye]
managed = true By this, no package created initially. ( |
I think I will add a version of this. I do find the "project only" moniker confusing. Currently thinking of just calling it "virtual" and not be too descriptive about what this means. |
Closing in favor of updated #551 |
[WIP] #236
For projects that do not need to be published as a package, add a "project-only" field for identification.
Welcome everyone to express their own opinions.