docs: Update this super old readme

[kdmccormick]

This directory was created as part of an idea [1]
to create top-level openedx namespace which
every Open edX package, including those in other
repos, would nest itself under. The README
was written with that in mind.

That never panned out, so openedx is really just
another "common" directory. Non-common code
should not be added to it. This update clarifies that.

[1] #5942 (comment)

[bradenmacdonald]

I guess it would be too difficult to move lms and cms to openedx.lms and openedx.cms ?

[bradenmacdonald]

Thanks for updating this. There are quite a few apps we should move into cms then: content_libraries, content.search, content_staging, olx_rest_api, core.lib.xblock_serializer, and maybe content_tagging although it may have LMS uses eventually.

[kdmccormick]

I guess it would be too difficult to move lms and cms to openedx.lms and openedx.cms ?

It's doable with some effort, I've done similarly big moves of directories before (e.g. common/lib/xmodule/xmodule to xmodule), but the question would be-- why? So edx-platform can have one code root? I think that would be nice for our tooling, but I see it as less important than keeping some architectural boundaries between cms and lms. So I think this is the right update for now, and I'm open to considering directory moves in the future, especially if someone is willing to contribute the refactoring.

[kdmccormick]

There are quite a few apps we should move into cms then

100%

Somewhere in my long-term-backlog is writing up a plan to move a ton of apps around so that edx-platform makes more sense. The challenging part is tha many edx-platform plugins import the code directly-- which is bad, and shouldn't be done in new plugins, but so many old plugins do it. Two options are:

• Use strategy similar to the one we used for the sys-path-dehacking to provide a 1- or 2-release window where plugin authors can migrate from old import paths to new ones
• Deprecate all support for importing edx-platform from external repos. Plugins would either have to switch to real extension points, or stop working.

[bradenmacdonald]

@kdmccormick Sounds good. At least for the few newer apps like the ones listed here, both plugins and edx-platform code should only have been importing from the api entry point, so we only have to alias that. We've had the linter enforcing that for edx-platform apps, and for plugins I don't think we have to worry as there are no old plugins using those apps, and new ones should be sticking to the api modules.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.