-
-
Notifications
You must be signed in to change notification settings - Fork 469
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
Unable to use Hatch Context Formatting
feature to format paths to local dependencies
#826
Comments
Possibly related to #800 |
That is unrelated. The issue here is from my perspective that hatch is doing something that the standard does not really suggest should work. How should a tool like rye understand which proprietary extensions are used in that dependency array? |
The odd thing is that this works if the package using this local dependency and exact syntax works when being a member of the rye workspace when specified at the root of the repository i.e. Instead of "rooting" this at the root of the repository, I am trying to run Outputs to follow later today if I were to do away with this syntax and use |
Oddly enough, the Given the folders Given the same set of folders, if |
That's most likely because in that case |
I wouldn't say encourages but rather that syntax allows for certain use cases that are otherwise difficult or impossible to represent in a correct and cross-platform fashion. |
if rye resolves to the absolute local path, how's it possible then to add local dependencies that can be reproducable in other machines as well? For example in a docker image, passing the local dependency as a build context is straightforward however the path won't be the same |
Rye's first response to this is workspaces. That's how rye solves "local dependencies" without having to specify any paths, then all the packages have to share a workspace and no absolute paths end up in the lockfile. Then there is incomplete support for relative paths dependencies in some ways for the pdm build backend (rye init option), where no absolute paths end up in the lockfile. The more general case for how path deps should work is pending work and design I think. |
@bluss I understand, workspaces don't solve though the issue with workspace packages running in separate envs (whenever there's a specific reason to do so) to avoid dependency conflicts. See this comment: #1023 (comment) |
Workspaces will be coming to Hatch next month. |
Steps to Reproduce
pyproject.toml
with the hatch build system i.e.rye sync
Expected Result
rye sync
should complete successfully without errors and with the respective lock files created.Actual Result
When working with a local dependency
"util @ file:///{root:parent}/util"
Without
uv
:With
uv
:Do note that
file:///{root:parent}/util
, when resolved by Hatch, resolves tofile:////path/to/my/project/python/lib/util
. Seems like Rye is checking the URLs before being resolved properly by the build system?Version Info
Stacktrace
No response
The text was updated successfully, but these errors were encountered: