-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[pypi] Add badge for django version support #1286
Conversation
Hi, thanks for this! Here's a quick response to your question:
We've got an impending rewrite of all the service code, so yes! Tests are basically half the work of the rewrite, so full steam ahead on those. As far as major refactoring, it's probably best to hold off until the rewrite. If it's a matter of extracting a couple helper functions as we prepare for the rewrite, definitely, feel free. Helpers should get their own unit tests. The reason to avoid major refactoring now is that it'll cause duplication of work coding and reviewing. Your time and the maintainers' time is better spent writing more tests, and putting in place the rest of the groundwork for the rewrite. |
OK. Thanks for the extra info @paulmelnikow . I'll look at adding some tests but hold off on refactoring. One observation I have about this project is that a lot of of your tests depend on external services. i.e: the tests may start fail because of something that has changed outside of your codebase. This also seems to be causing some other problems. Again, I'm aware that the tests I've added here have the same problem due to the structure. Given you're planning to refactor a lot of this code, would I be right to assume one of the things you're hoping to do is to decouple the code that reaches out to external services from the code that processes the responses? That would make it easier to test the code against mocked responses which would make the tests more deterministic and help with some of these other issues. I realise I've strayed a bit from the original point of adding a badge to display django version support. If it is better to reply under another issue, feel free to move the conversation elsewhere and @ mention me. |
7ddaac4
to
818c7c4
Compare
818c7c4
to
ccc12a7
Compare
I've rebased this on to master and tweaked the tests to account for your feedback on #1289 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left you a few comments.
lib/all-badge-examples.js
Outdated
@@ -1299,6 +1299,14 @@ const allBadgeExamples = [ | |||
'python' | |||
] | |||
}, | |||
{ | |||
title: 'PyPI', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title should be PyPI – Django version or maybe just Django version, and it's probably worth adding pypi
to keywords.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! That sounds great.
server.js
Outdated
@@ -2094,7 +2094,7 @@ cache(function(data, match, sendBadge, request) { | |||
} | |||
try { | |||
var parsedData = JSON.parse(buffer); | |||
if (info.charAt(0) === 'd') { | |||
if ((info === 'dm') || (info === 'dw') || (info ==='dd')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can omit the parens around these, since ||
binds at a lower precedence. Everywhere but server.js
I think the linter will catch it.
server.js
Outdated
if (!versions.length) { | ||
versions.push('not found'); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you extract some the version parsing and formatting into a helper function in lib/pypi-helpers.js
?
service-tests/pypi.js
Outdated
@@ -4,6 +4,7 @@ const Joi = require('joi'); | |||
const ServiceTester = require('./runner/service-tester'); | |||
const { isSemver } = require('./helpers/validators'); | |||
const isCommaSeperatedPythonVersions = Joi.string().regex(/^([0-9]+.[0-9]+[,]?[ ]?)+$/); | |||
const isCommaSeperatedDjangoVersions = Joi.string().regex(/^([0-9]+.[0-9]+[,]?[ ]?)+$/); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These regexes are the same. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - they're the same regex being used to validate 2 different things which is why I've assigned that regex to 2 different names. I did think about this myself and thought about:
const isCommaSeperatedPythonVersions = Joi.string().regex(/^([0-9]+.[0-9]+[,]?[ ]?)+$/);
const isCommaSeperatedDjangoVersions = isCommaSeperatedPythonVersions;
or
const isCommaSeperatedPythonOrDjangoVersions = Joi.string().regex(/^([0-9]+.[0-9]+[,]?[ ]?)+$/);
but I think the way I've written it make it most clear. There's no meaningful performance consideration here so it is all about readability. Do you prefer a different notation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, makes sense. Maybe just throw in a comment with that rationale?
// These regexes are the same, but defined separately for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great!
|
||
|
||
// extract classifiers from a pypi json response based on a regex | ||
const parseClassifiers = function(parsedData, pattern) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could I ask you to write unit tests for these functions? There are some nice data-driven tests in lib/lua-rocks-version.spec.js, among others.
let versions = parseClassifiers( | ||
parsedData, | ||
/^Programming Language :: Python :: ([\d.]+)$/ | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
added |
|
||
given(["2.0rc1", "10", "1.9", "1.11", "2.1", "2.11",]) | ||
.expect(["1.9", "1.11", "2.0rc1", "2.1", "2.11", "10"]); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This PR adds the django version support feature suggested in issue #1018
Having worked on this issue, I note that:
As a further piece of work, I would also be interested in adding more tests to support refactoring this into a number of smaller functions and also having a go at some of that refactoring work. Would you be open to receiving some further PRs?
Closes #1018