-
Notifications
You must be signed in to change notification settings - Fork 21
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
New locators for content libraries #46
Conversation
Thanks for the pull request, @bradenmacdonald! I've created OSPR-167 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams. Feel free to add information to the ticket which can help Product understand the context for the PR - supporting documentation, edx-code email threads, timeline information ('this must be merged by XX date', and why that is), partner information (this is for a course on edx.org, for example), etc. All technical communication about the code itself will still be done via the Github pull request interface. As a reminder, our process documentation is here. We can't start reviewing your pull request until you've added yourself to the AUTHORS file. Please see the CONTRIBUTING file for more information. |
Thanks! Can you fix up the pylint violations, so that this branch passes the Travis build? |
Hey @bradenmacdonald : this makes sense to me. I'm wondering if there's any supporting documentation you might have to add to this (ie did you discuss this on edx-code?) - also be sure to add yourself to Also check your diff-cover report and see if you can up your coverage: |
587eec2
to
602ffb3
Compare
621cef7
to
e1bb028
Compare
e1bb028
to
0c49a27
Compare
Ok, I have fixed the quality issues and increased the coverage to 100%. @sarina The technical design is at https://openedx.atlassian.net/wiki/display/SOL/Content+Libraries . It was posted to the mailing list but virtually all the discussion happened on that wiki page. I then presented it to the Arch Council and this got the green light after a fruitful discussion. This is for an edX solutions client and we are hoping to get it approved and ASAP so that we can use it in the content libraries prototype coming soon to edx-platform. |
block_id = self._parse_block_ref(block_id, False) | ||
|
||
if not all(self.ALLOWED_ID_RE.match(val) for val in (block_type, block_id)): | ||
raise InvalidKeyError(self.__class__, "Invalid block_type or block_id") |
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.
Would be great if actual block_type and block_id are somehow incorporated into exception, or at least logged
@bradenmacdonald most of the test can be converted to data-driven tests (I've marked some of them explicitly). The benefit of using ddt is that the test code is much DRY-er and allows for adding new test cases much simpler. Other than that - looks good. |
6d7533d
to
8bfec4d
Compare
@bradenmacdonald tests & code looks clean, moving this forward to team review. |
({BRANCH_PREFIX}@(?P<branch>{ALLOWED_ID_CHARS}+)\+?)? | ||
({VERSION_PREFIX}@(?P<version_guid>[A-F0-9]+)\+?)? | ||
({BLOCK_TYPE_PREFIX}@(?P<block_type>{ALLOWED_ID_CHARS}+)\+?)? | ||
((?P<org>{ALLOWED_ID_CHARS}+)\+(?P<course>{ALLOWED_ID_CHARS}+)(\+(?P<run>{ALLOWED_ID_CHARS}+))?(\+(?=.))?)?? |
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 don't understand why you added ?=.
which seems to be a noop: "there may be a plus sign here or anything else. If plus sign, eat it, if it's anything else, don't read it in" seems equivalent to "there may be a plus sign here. If so, eat it."
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 noticed this pattern would match URLs with a trailing plus, e.g. course-v1:BradenX+PHYS200+2014+
which seems weird - with this change to add a lookahead, a lone trailing +
is no longer matched. It's not important for the libraries, just something I saw while re-working to make run
optional.
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.
ah, I misread the pattern. Perhaps add a comment string as w/ all the ? it gets hard to humanly read? Anyway, good catch.
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 feel like we're getting past the point where a regex for parsing makes this easier to read. I almost implemented imperative to parse the same, but held off. Still, seems like it might be worth considering a different parsing solution (combinators, maybe?)
self.assertEqual(version_only_lib_key.package_id, None) | ||
with self.assertRaises(InvalidKeyError): | ||
version_only_lib_key.for_branch("test") | ||
|
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.
at this point my eyes glaze over and I assume you've continued this systematic thoroughness through the rest :-)
👍 |
Thanks for the review! I've pushed two new commits with the suggested changes. Highlights are:
|
New locators for content libraries
This PR implements two new types of locators necessary to facilitate content libraries. I'll be posting a separate PR to edx-platform for the content libraries prototype soon, but for now I'd like to start the review process for this locator code.
The new locators are described in detail under the "New Locators" heading at https://openedx.atlassian.net/wiki/display/SOL/Content+Libraries