I'm curious how common my use-case / desire is here. I suspect this is uncommon, but not exceedingly rare.
I have a project that has several dependencies I would like to install locally so that I can develop the main project and those dependencies. The trouble is that those dependencies already have homes which shouldn't/can't change, and shouldn't be vendored into the main project's repository. The main project should be easy to use, and generally run well with the dependencies coming from their normal source (e.g. pypi), and this would be the common use of the main project.
Currently, as a workaround, I clone the dependencies, comment out the line in the pyproject.toml that referenced them, and rye add dep --path ../dep --absolute (relative paths seem to have other issues currently). I don't have a solution that doesn't involve making a change to the pyproject.toml, or a resultant change to a lock file. This workaround keeps things easy for most users, but is a bit of a pain for some developers like me.
A solution might look like a pyproject.toml including a dependency in dependencies and define a workspace that may be empty, or have that dependency present in the workspace. If found in the workspace, that version could be used instead of the one in the dependencies array.
Another would be to allow a local source to be defined. I don't think that's possible now. Something like
[[tool.rye.sources]]
name = "local"
path = ".."
type = "path" # seems redundant given the absence of `url` and presence of `path`
Or another, to allow a variant dependency syntax to specify that an installation path should fall back to a typical installation. I'm not sure the best way to indicate a fallback to dep @ file:///path/dep"
If there are other suggestions for how to handle the general situation now, I'd love to hear them. Thanks!
I'm curious how common my use-case / desire is here. I suspect this is uncommon, but not exceedingly rare.
I have a project that has several dependencies I would like to install locally so that I can develop the main project and those dependencies. The trouble is that those dependencies already have homes which shouldn't/can't change, and shouldn't be vendored into the main project's repository. The main project should be easy to use, and generally run well with the dependencies coming from their normal source (e.g. pypi), and this would be the common use of the main project.
Currently, as a workaround, I clone the dependencies, comment out the line in the pyproject.toml that referenced them, and
rye add dep --path ../dep --absolute(relative paths seem to have other issues currently). I don't have a solution that doesn't involve making a change to the pyproject.toml, or a resultant change to a lock file. This workaround keeps things easy for most users, but is a bit of a pain for some developers like me.A solution might look like a pyproject.toml including a dependency in
dependenciesand define a workspace that may be empty, or have that dependency present in the workspace. If found in the workspace, that version could be used instead of the one in thedependenciesarray.Another would be to allow a local source to be defined. I don't think that's possible now. Something like
Or another, to allow a variant dependency syntax to specify that an installation path should fall back to a typical installation. I'm not sure the best way to indicate a fallback to
dep @ file:///path/dep"If there are other suggestions for how to handle the general situation now, I'd love to hear them. Thanks!