Vendored dependencies are saved with a full file path specific to the machine

[crimsonknave]

When you have a dependency configured like "name @ {root:uri}/vendor/name.1.zip" the requirements.txt file will have the full path like file:///home/user/code/project/vendor/name.1.zip. Everything works when another person runs it on another machine, but the requirements file will have been updated to have the path on their machine, which causes git churn.

Can the requirements.txt file store the entry with a relative path or keeping the {root:uri} present?

[juftin]

Could you give me an example pyproject.toml. Are you describing something like this?

[project]
name = "hatch-pip-compile-example"
version = "0.1.0"
dependencies = [
    "requests",
    "camply @ file:///Users/juftin/git/camply"
]

[tool.hatch.env]
requires = [
    "hatch-pip-compile"
]

[tool.hatch.envs.default]
type = "pip-compile"

[tool.hatch.metadata]
allow-direct-references = true

[crimsonknave]

We have packages stored in the vendor directory and checked in (it's bad and I hate it, but it's what we have now) and do not use a direct file path in the pyproject.toml, instead we use the root:uri so that the path works across different developers machines.

[project]
name = "hatch-pip-compile-example"
version = "0.1.0"
dependencies = [
    "requests",
    "camply @ {root:uri}/vendor/camply-1.0.0.zip"
]

[tool.hatch.env]
requires = [
    "hatch-pip-compile"
]

[tool.hatch.envs.default]
type = "pip-compile"

[tool.hatch.metadata]
allow-direct-references = true

[juftin]

Oh wow, just realizing how late my reply is here. Sorry about that 😅

Is the issue here the header of the lock file, or the lock file itself having these absolute instead of relative paths?

[crimsonknave]

Oh wow, just realizing how late my reply is here. Sorry about that 😅

No worries.

Is the issue here the header of the lock file, or the lock file itself having these absolute instead of relative paths?

My requirements/requirements-dev.txt contains the full paths for anything that uses root:uri. So, it's the contents of the file itself, not sure exactly what you mean by the header, but the file is named as expected. The requirements/requirements-dev.txt would look like this.

#
# This file is autogenerated by hatch-pip-compile with Python 3.12
#
# - camply@ file:///path/to/app/vendor/camply-1.0.0.zip
# ...

camply @ file:///path/to/app/vendor/camply-1.0.0.zip
...

[juftin]

The first part commented out is the hatch-pip-compile header and that absolute path is actually inferred via hatch and not from some custom code in hatch-pip-compile. These dependencies are then passed down intopip-compile` and that's how the absolute path ends up in the lockfile body. I will need to think about this one, I think I may need to do some work with the upstream output from hatch to make this work.