-
Notifications
You must be signed in to change notification settings - Fork 19
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
feat: use packaging
to parse requirements
#735
base: main
Are you sure you want to change the base?
feat: use packaging
to parse requirements
#735
Conversation
bad3487
to
1cc9ba7
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #735 +/- ##
=======================================
+ Coverage 92.8% 93.1% +0.3%
=======================================
Files 35 35
Lines 920 888 -32
Branches 165 154 -11
=======================================
- Hits 854 827 -27
+ Misses 52 49 -3
+ Partials 14 12 -2 ☔ View full report in Codecov by Sentry. |
1cc9ba7
to
f9ddda5
Compare
packacing
to parse requirementspackaging
to parse requirements
I do like the idea of using
In the link you share to the pip documentation, they suggest use PEP 508 format for installing from a package index. But they also show that they support other formats for packages that do not come from a package index. So I do think it would be good to keep supporting the formats in Can we maybe do both for |
Between the 2 options, I'd personally prefer the first one, as I still think though that trying to guess the package name from a random URL on which we have no real control on feels quite hacky, even if most of the time this should give the user the expected result. I'll put back the PR as a draft for now until I find the time to get back to this. |
PR Checklist
docs
is updatedDescription of changes
This is something that has been on my mind for quite some time now.
We currently rely on several regexes to parse dependencies in requirements files. Although this allows parsing formats that
pip
handles, there are many formats that PEP 508 does not cover, as both remote dependencies and local dependencies need to follow<package> @ <path>
format. Even pip documentation suggests to use PEP 508 format.The usage of regexes itself definitely makes the parsing best-effort, but it could also creates some false positives, as for instance for what looks like git URLs, we try to guess where the package name is, based on the git project name in the URL, which could depend on the git server used, or, worse, the git project name could be different than the real Python package name.
This PR suggests using packaging, maintained by PyPA, to parse dependencies where we expect PEP 508 format to be used (requirements files, PEP 621 metadata). This would remove support for URLs that do not follow PEP 508 dependencies, so this is a breaking change we would have to mention in the changelog, if we effectively want to go this way.