Lockfile support generates an incorrect lockfile for any direct reference requirement.

[jsirois]

Pants, via pkg_resources.Requirement, handles direct reference requirements as described here: https://www.python.org/dev/peps/pep-0440/#direct-references

These requirements parse with no version as demonstrated here:

$ pex setuptools -- -c 'from pkg_resources import Requirement; req = Requirement.parse("darglint @ git+https://github.com/thejcannon/darglint@XYZ"); print(f"req: {req} spec: {req.specifier}")'
req: darglint@ git+https://github.com/thejcannon/darglint@XYZ spec:

This is problematic with our current lock file implementaion using Poetry since:

pants/src/python/pants/backend/python/subsystems/poetry.py

Line 97 in 315dd5c

version=str(requirement.specifier) or None, # type: ignore[attr-defined]

pants/src/python/pants/backend/python/subsystems/poetry.py

Line 107 in 315dd5c

metadata: dict[str, Any] = {"version": dep.version or "*"}

pants/src/python/pants/backend/python/subsystems/poetry.py

Lines 68 to 76 in 315dd5c

	def create_pyproject_toml_as_dict(
	raw_requirements: Iterable[str], interpreter_constraints: InterpreterConstraints
	) -> dict:
	python_constraint = {"python": interpreter_constraints.to_poetry_constraint()}
	project_name_to_poetry_deps = defaultdict(list)
	for raw_req in raw_requirements:
	# WONTFIX(#12314): add error handling.
	req = Requirement.parse(raw_req)
	poetry_dep = PoetryDependency.from_requirement(req)

That generates a pyproject.toml with an incorrect dependency entry for every direct reference requirement we are trying to lock using poetry lock on the pyproject.toml. Instead of getting a lock on the direct reference requirement you specify and instead of failing to indicate we can't generate a proper lock for these, we silently generate a lock against the latest publically available version of the project on PyPI (since we say version = "*").

[cognifloyd]

Can this be closed now that we use pex lockfiles?

[jsirois]

Yes. Pex does proper hashing of these on both the generate and consume side.