Join GitHub today
Replace the PEP-386 parser for the more general PEP-440 #860
This means we drop the vendor and not really tested
Slight refactor of the functions affected to make them more readable.
@@ Coverage Diff @@ ## master #860 +/- ## ====================================== - Coverage 93% 92% -<1% ====================================== Files 12 12 Lines 2326 2331 +5 Branches 408 408 ====================================== + Hits 2153 2155 +2 - Misses 107 110 +3 Partials 66 66
Both the functions and variables are related to PR: I've refactored the code handling the dependency parsing: As part of the dependency parsing the version parsing is used and as such the version parser is invoked via the
Private functions are that private. They don't promise any compatibility. So there was no compatibility guarantee there in the first place.
Git blame has little value overall (especially given no one in the git blame are maintaining the library currently), compared to maintaining the library. Recently I've tried adding type information to the library, and the version library what we don't test was a major pain point to showcase an example. I value an easy to read code over maintainability any day.
I'm changing the behaviour ever so slightest, as note PEP-440 is a bit more permissive than PEP-338 (e.g.
I've kept the private function as it was but made it deprecated. We'll remove later on. As migration path, you can use the public
Jun 29, 2018
@gaborbernat, what's your opinion of the tests for this? Are we covering enough with the existing tests to be reasonably sure that this does not introduce any surprises? I did not have the time to have a closer look or even to check the branch out and play with it to look for potential problems, so I am merely curious at the moment.
@obestwalter I think we're covering enough. That being said this might break some people; who were relying on the less permissive PEP-386 logic. E.g.