Closed macro1 closed 6 months ago
The change looks good to me (we'll need a unit test, though). The CI failure is unrelated, I'll look into it.
A better approach may be to return something different than InstallRequirement
Do you have anything in mind?
The change looks good to me (we'll need a unit test, though). The CI failure is unrelated, I'll look into it.
A better approach may be to return something different than InstallRequirement
Do you have anything in mind?
I was mainly thinking we could add a new structure containing the InstallRequirement
and any other attributes pip-tools may need to track. However, I understand that it would impact many internal interfaces, which could pose some challenges.
Ah yes, I love Windows, too. Will review soon.
@macro1 Could you look into fixing the linting errors?
Accomplishes preservation of relative dependency paths by reverting back to input requirements definition for editable dependencies.
There are a couple prior attempts of this. The two I read through treated this like a formatting problem, I'm not sure it is. The issue, as has been pointed out in #204 is that paths are converted into urls in the form of absolute paths within pip.
If we maintain knowledge of the original relative paths within pip-tools, the values will be maintained more faithfully, and the complexity should be lower.
This PR accomplishes it by forcing the return value from
parse_requirements()
to give the values we need elsewhere. A better approach may be to return something different thanInstallRequirement
or preserve the relationship with the parsed requirement and provide both where it makes sense.Contributor checklist
Maintainer checklist
backwards incompatible
,feature
,enhancement
,deprecation
,bug
,dependency
,docs
orskip-changelog
as they determine changelog listing.