build!: Switch to openedx-core (renamed from openedx-learning)

[kdmccormick]

Description

Instead of installing openedx-learning==0.32.0, we install openedx-core==0.34.1.
We update various class names, function names, docstrings, and comments to
represent the rename:

• We say "openedx-core" when referring to the whole repo or PyPI project
  • or occasionally "Open edX Core" if we want it to look nice in the docs.
• We say "openedx_content" to refer to the Content API within openedx-core,
  which is actually the thing we have been calling "Learning Core" all along.
  • In snake-case code, it's *_openedx_content_*.
  • In camel-case code, it's *OpenedXContent*

For consistency's sake we avoid anything else like oex_core, OeXCore,
OpenEdXCore, OexContent, openedx-content, OpenEdxContent, etc.
There should be no more references to learning_core, learning-core, Learning Core,
Learning-Core, LC, openedx-learning, openedx_learning, etc.

BREAKING CHANGE: for openedx-learning/openedx-core developers:
You may need to uninstall openedx-learning and re-install openedx-core
from your venv. If running tutor, you may need to un-mount openedx-learning,
rename the directory to openedx-core, re-mount it, and re-build.
The code APIs themselves are fully backwards-compatible.

Testing

I smoke tested libraries and django admin on my own tutor dev, confirmed that bind-mounting works with the new repo. Will do the same smoke tests on the PR sandbox.

Supporting info

ADR: https://github.com/openedx/openedx-core/blob/main/docs/decisions/0021-openedx-core.rst

Part of: openedx/openedx-core#470
Follows up from openedx/openedx-core#471

Merge deadline

This week, ideally, so we don't exist in confusing semi-renamed state for long

[bradenmacdonald]

Super nit: In quite a few places in this PR we have openedx-core-based which sounds like a package name. I think "based on openedx-core" (or something along those lines) is better, though it doesn't lend itself well to find-and-replace.

[bradenmacdonald]

I renamed the folder, updated my mount points, rebuilt my openedx-dev image, and this seems to be working fine. I have those questions about how we're naming some of these things ^ but it's not blocking.

[kdmccormick]

Thanks for the feedback. I'm a little torn on openedx-core vs. openedx_content. Neither name is very "catchy" and could easily be confused with existing parts of openedx-platform (like the openedx/core folder, or "contentstore").

Maybe it makes sense just to be precise. We can say openedx_content whenever we're talking just about the Content API, and say openedx-core whenever we're talking about the whole repo. After all, parts of openedx-core will end up being used for content from both ModuleStore and openedx_content... Pathways (from openedx-core) will contain CourseRuns (whose content is in ModuleStore). Any block can have tags from openedx_tagging. etc.

I pushed a separate commit which does that. Let me know what you think @bradenmacdonald .

[kdmccormick]

@bradenmacdonald tangential question: what purpose is the XBlockRuntime class serving? could it be merged into OpenedXContentRuntime?

[bradenmacdonald]

I guess I was hoping that we'd implement a ModulestoreRuntime which derives from XBlockRuntime for more consistency in our runtimes, but nothing has panned out. I think it would be fine to merge them together.

[kdmccormick]

gotcha. I wrote up #38021

[bradenmacdonald]

@kdmccormick Thanks for those changes. I'm a little torn as well, but I think your changes and general approach makes sense. ✅

[kdmccormick]

thanks @bradenmacdonald ! fyi I pushed a couple more trivial comment updates that I just found: 5099a35 . I'll merge once tests pass unless you have any objection.