Skip to content
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

uv lock: relative sdist for relative path dependencies #3965

Closed
considerate opened this issue Jun 2, 2024 · 5 comments
Closed

uv lock: relative sdist for relative path dependencies #3965

considerate opened this issue Jun 2, 2024 · 5 comments

Comments

@considerate
Copy link

considerate commented Jun 2, 2024

Given a requirements.txt file that includes a relative path to a directory containing a distribution:

../my-package

With uv pip compile --unstable-uv-lock-file requirements.txt the generated lock has the package resolved to absolute paths like the following:

[[distribution]]
name = "my-package"
version = "0.1.0"
source = "directory+file:///home/me/path/to/my-package"

[distribution.sdist]
url = "file:///home/me/path/to/my-package"

This is not ideal since I want to commit the lock file to a git repo shared with other people and they won't have the same directory structure I have.

  1. Is it possible to update the lock files to instead retain the relative path that was specified in the requirements.txt file?
  2. Is there any other way to declare relative path dependencies that would not have this absolute path resolution?
@considerate
Copy link
Author

Note:
Specifying the dependency as file:../my-package results in the same output.

@considerate
Copy link
Author

Possibly related to #3506

@considerate
Copy link
Author

For reference, poetry with a my-package = {path = "../my-package"} dependency resolves to:

[[package]]
name = "my-package"
version = "0.1.0"

...

[package.source]
type = "directory"
url = "../my-package"

@charliermarsh
Copy link
Member

👍 Yeah this will certainly change. I am going to merge into #3506 since it's meant to cover the same problem.

@charliermarsh charliermarsh closed this as not planned Won't fix, can't repro, duplicate, stale Jun 2, 2024
@charliermarsh
Copy link
Member

I don't believe there's any way around this with the lockfile right now. (It's not really intended for public use yet.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants