I have refactored some of the cli unit tests to check results from test and update (using --dry). I refactored the implementation so that test uses the same code to translate to pep440 as update.
However, I ran into a problem with this approach where some (most?) possible v1 patterns don't have a useful mapping to a pep440-compliant format, resulting in no handling whatsoever for such patterns. I note that using the {pep440_version} replacement pattern does not seem to work in these cases either. For now I have worked around this by falling back to the old pep440 handling in this specific case, which at least means those v1 patterns can be used without the {pep440_version} replacement pattern.
Ultimately I chose not to change the handling of update, because I expect that current users would be relying more heavily on those results, and changing those results is most likely to upset a few people. Please take a look and let me know your thoughts. I am interested to get a few opinions on this.
I have refactored some of the cli unit tests to check results from test and update (using --dry). I refactored the implementation so that test uses the same code to translate to pep440 as update.
However, I ran into a problem with this approach where some (most?) possible v1 patterns don't have a useful mapping to a pep440-compliant format, resulting in no handling whatsoever for such patterns. I note that using the {pep440_version} replacement pattern does not seem to work in these cases either. For now I have worked around this by falling back to the old pep440 handling in this specific case, which at least means those v1 patterns can be used without the {pep440_version} replacement pattern.
Ultimately I chose not to change the handling of update, because I expect that current users would be relying more heavily on those results, and changing those results is most likely to upset a few people. Please take a look and let me know your thoughts. I am interested to get a few opinions on this.