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.

[bradenmacdonald]

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.

You can specify whatever sort of exclude glob you want in pyproject.toml, so it's possible to exclude tests regardless of where you place them. I guess having a separate tests folder 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 thetests tree to find the corresponding tests, especially with deeply nested things. (If I change the components model for example, I'd need to run cd ../../../../../tests/openedx_learning/apps/authoring/applets/components/ to get to the test files). This won't be as bad after we move openedx_content to the top-level and if we put src and tests as subdirs of that.

We might also end up following uv conventions and putting things in a top level src dir as well.

Ah yeah, seems that https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/ has some solid reasons for recommending the src layout.