Repository navigation
Refactor so that openedx_content is a top-level package #468
Description
After #457 is complete, refactor so that the openedx_content app is a top level package in openedx-learning, rather than something inside of openedx_learning.apps. This work will also require that all openedx-platform references to these paths be updated.
It's also worth noting that the openedx_learning.lib package has modules that are used by openedx-platform for things like case_insensitive_char_field, in order to normalize behavior between SQLite and MySQL (e.g. for test consistency). I'm not clear on where these should go, since they're not really tied to openedx_content.
I think it's likely we'll want to use the openedx_learning name for another top level app that will have some Learning Pathways related code in it.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
Activity
openedx-core#470openedx_contentapp #457bradenmacdonald commentedon Feb 3, 2026
Even after #454 , test code is in kind of an awkward place, e.g.
tests/openedx_learning/apps/authoring/applets/publishing/test_api.pyAs we re-organize this to make
openedx_contenta top-level package, I think we should re-organize the tests as well. I personally much prefer to keep tests as close as possible to the code they cover, so I propose that for example, we have the tests foropenedx_content/applets/publishing/api.pyin a file namedopenedx_content/applets/publishing/api_test.pyoropenedx_content/applets/publishing/tests/test_api.py.But if there is some compelling argument for keeping tests in a completely separate folder, then would we want
openedx_content/testsortests/openedx_content/?bradenmacdonald commentedon Feb 3, 2026
One option is edx-django-utils. It's already a dependency of both this repo (indirectly) and openedx-platform. It would be nice to see more usage of those field types outside of this repo.
ormsbee commentedon Feb 4, 2026
I think the main argument for it is that it allows us to easily skip all the test related stuff during packaging, including whatever test data files we have for backup/restore tests. FWIW, I lean towards having the tests separate, but it's not something I feel strongly about.
My take would be
openedx_content/testsbecause I think that's just slightly friendlier to the notion of possibly lifting these things out into separate spaces in the future. But I really don't feel strongly on this, and I feel like it's something we can pretty easily adjust. We might also end up followinguvconventions and putting things in a top levelsrcdir as well.ormsbee commentedon Feb 4, 2026
Yeah, that makes sense.
bradenmacdonald commentedon Feb 5, 2026
You can specify whatever sort of
excludeglob you want inpyproject.toml, so it's possible to exclude tests regardless of where you place them. I guess having a separatetestsfolder is more common in python projects though, and it's not something I feel strongly about. I just get a little annoyed when I change some code in a file and it takes me some time to browse through theteststree to find the corresponding tests, especially with deeply nested things. (If I change thecomponentsmodel for example, I'd need to runcd ../../../../../tests/openedx_learning/apps/authoring/applets/components/to get to the test files). This won't be as bad after we moveopenedx_contentto the top-level and if we putsrcandtestsas subdirs of that.Ah yeah, seems that https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/ has some solid reasons for recommending the
srclayout.ormsbee commentedon Feb 5, 2026
I realize that you can enter patterns into the exclude glob, but a top-level tests dir lets you avoid accidentally removing things like
test_utils.py, which is meant to be a place to put helper classes, and isn't a test suite in and of itself. I tripped across that once, and while it was caught readily enough in CI for downstream things, it was still a case of something that wouldn't happen if we had separated it at the top level.FWIW, I usually just use VS Code to jump to the test files and run tests, which may explain why it doesn't bother me that they're so far away from each other.