Refactor so that `openedx_content` is a top-level package

[ormsbee]

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.

[bradenmacdonald]

Even after #454 , test code is in kind of an awkward place, e.g. tests/openedx_learning/apps/authoring/applets/publishing/test_api.py

As we re-organize this to make openedx_content a 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 for openedx_content/applets/publishing/api.py in a file named openedx_content/applets/publishing/api_test.py or openedx_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/tests or tests/openedx_content/?

[bradenmacdonald]

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.

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]

As we re-organize this to make openedx_content a 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 for openedx_content/applets/publishing/api.py in a file named openedx_content/applets/publishing/api_test.py or openedx_content/applets/publishing/tests/test_api.py.

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.

But if there is some compelling argument for keeping tests in a completely separate folder, then would we want openedx_content/tests or tests/openedx_content/?

My take would be openedx_content/tests because 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 following uv conventions and putting things in a top level src dir as well.

[ormsbee]

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.

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.

Yeah, that makes sense.