Refactors and reworks the LibraryContentBlock so that its
sync-from-library operations are asynchronous and work with
V2 content libraries. This also required us to make
library_content block duplication asynchronous, as that
involves syncing from the source library.
For the sake of clarity, this PR includes two major method renames:
* update_children(...) -> sync_from_library(...)
* refresh_library(...) -> sync_from_library(upgrade_to_latest=True, ...)
an an XBlock HTTP handler rename:
/refresh_children -> /upgrade_and_sync
There are still a couple issues with import or duplication
of library_content blocks referencing V2 libraries other than
latest. These will be resolved in an upcoming PR.
Part of: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3820617729/Spec+Memo+Content+Library+Authoring+Experience+V2
Follow-up work: https://github.com/openedx/edx-platform/issues/33640
Co-authored-by: Connor Haugh <chaugh@2u.com>
Co-authored-by: Eugene Dyudyunov <evgen.dyudyunov@raccoongang.com>
paver for js test is discussed below separately
python testing is covered well in the next section, running all python
tests is not useful for development loops
Originally, we planned to add support for V2 libraries and for static
(hand-selected) library block reference via new block type: library_sourced.
We have since decided that it would be better to add those capabilities
in-place to the existing library_content block. This will ease V1->V2
library migration and make adoption of the new features easier for current
library users. It will also avoid duplication of logic between two block types,
we we fear would be error-prone. For details, see this ADR:
https://github.com/openedx/edx-platform/pull/33231
So, we are removing the library_sourced block.
This block has existed in edx-platform for a few years now, but was not
enabled by default and never officially supported. It was only usable via the
experimental V2 content library feature. Operators who added library_sourced
blocks to their course will now see them render as `HiddenBlock` instances, i.e.:
> ERROR: "library_sourced" is an unknown component type...
This should not impact other component types in such courses and should not
impact import/export.
Implements the `npm run watch` section of the assets ADR [1], plus some
modifications since I decided to switch from pywatchman to watchdog (see
ADR changes for justification). This will replace `paver watch_assets`
(edx-platform) and `openedx-assets watch-themes` (Tutor).
Specifically, this PR adds three experimental commands:
* `npm run watch-sass` : Watch for Sass changes with watchdog.
* `npm run watch-webpack` : Invoke Webpack-watch for JS changes.
* `npm run watch` : Invoke both `watch-sass` and `watch-webpack` simultaneously.
These commands are only intended to work in development mode. They have
been tested both on bare-metal edx-platform and through `tutor dev run`
on on Linux.
Before removing the "experimental" label, we need to:
* Test through Devstack on Linux.
* Test through Devstack and `tutor dev run` on macOS.
* Test on bare-metal macOS. Might not work, which is OK, but we should
document that.
* Document the commands in edx-platform's README.
* Confirm that this not only works through `tutor dev run`, but also as
a suitable replacement in the `watchthemes` service that Tutor runs
automatically as part of `tutor dev start`. Tweak if necessary.
References:
1. https://github.com/openedx/edx-platform/blob/master/docs/decisions/0017-reimplement-asset-processing.rst
Part of: https://github.com/openedx/edx-platform/issues/31612
Now that the content in `guides` is all of the edx-platform docs, move
them all into the top-level docs directory to reduce confusion.
BREAKING CHANGE: Guides are now just docs. This will require updating
the publishing settings so that RTD looks for the conf in a different
location.
We publish the two pages that were being published under here to the new
edx-platform docs under docs.openedx.org so update this doc site to
redirect to that site for all pages.
Once this version has been published, we should be safe to remove this
doc project from the platform and all future changes should go through
the single edx-platform docs site.
We ran into memory issues at RTD so skip the xmodule, cms and common
docs for now so we can get some of the stuff up. We can come back to it
later once we make things better.
Since we want to replace the existing technical docs with this guides
project and we already build the technical docs into this project now.
Adding these redirects will allow it to be a drop-in replacement for the
existing published technical docs project.
We want to be able to move pages around and have sphinx automatically
redirect to the now location when that happens. This will allow us to
re-organize safely as we figure out the best way to layout the
documentation.
There is still a lot of improvements that could be made to make the
generated docs better organized. However, before this change we were
generating the docs but they weren't in the doc tree so you couldn't
actually browse to them. So we fix that first so that we can start
getting feedback about how to organize them.
This adds the ability to get a list of detailed courses based on their
keys provided in the newly added `keys` query param in the `GET /courses/v1/courses/`
endpoint.
With this move we don't need the existing separate `edx-platform
Technical` sphinx project. In the future we can remove it and just
redirect to the content in this project but I won't be doing that as a
part of this change because that involves adding redirects over there to
the new content and I'm not yet done organizing the destination.
The docs in the `guide` project might move around as we make the project
follow diataxis more closely.
* Swagger was renamed to OpenAPI at some point so use the new name for
clarity.
* Prefix with `lms` to make it clear that these are the APIs from the
LMS and may not all be available in the CMS.
* This project was not being published anywhere.
* The previous commit that adds openapi generation capabilities to the
`docs/guides` replaces what this was doing.
We get about one email per month from people looking for access to edX
APIs. Those emails come to the now almost-defunct oscm@edx.org email
address. I think that's because of these swagger references.
I suppose someone could find this email address on an Open edX
installation, and people would write to it, but I find in practice this
doesn't happen.
Co-authored-by: Kyle McCormick <kyle@tcril.org>
