There is the pretty old feature called Content Libraries. Long story short for those who are not familiar whit it: libraries allows you to create predefined pool of components which you can reuse in your course.
That libraries are known as V1 Libraries. In a nutshell they are modulestore-based blocks.
As for now, there is ongoing work on implementing so called V2 Libraries - blockstore-based components with the same purpose as the V1 libraries. Check the blockstore repo and frontend-app-library-authoring repo for details.
Considering that support for both V1 and V2 libraries simultaneously will require a lot of effort and this ADR discussion I would like to discuss/clarify the following:
When it is planned to move from the V1 to V2 libraries usage?
Is there any deprecation ticket already created?
Will there be a tool to migrate V1 libraries to the blockstore?
How much the community relies on the V1 libraries usage now?
Please, be welcome to add any suggestions/concerns you have!
Not necessarily. I don’t think much effort is required to maintain V1 libraries. They are not being developed in any way, but nor do they require much maintenance.
I’m not sure. But I can say this: lots of new features and functionality are being built with V2, and no changes are being made to V1. So when people want to take advantage of the new features, they’ll need to use V2.
No, because I don’t think there’s any specific plan to deprecate V1 yet. I’m sure it will eventually happen but V2 needs more functionality before that can be planned. I may be out of the loop though.
As far as I know there is no such tool at the moment, but it should be straightforward to develop. The main missing piece is that modulestore’s OLX export REST API only works with courses, not libraries. Once that’s fixed to work with V1 libraries as well (probably relatively easy to do), you could easily write a script to export all content from a V1 to a V2 library using REST APIs alone:
Use the Library V1 API to list all the XBlocks in a library, e.g. GET http://studio.example.com/library/library-v1:BradenX+101?format=json
Use the (fixed) OLX export API to get the OLX and static file data for each block in the library (e.g. GET http://studio.example.com/api/olx-export/v1/xblock/lib-block-v1:BradenX+101+type@html+block@12345/)
Use the libraries V2 REST API to create a V2 library and upload the OLX+static files for each XBlock from the V1 library.
We have made very similar scripts [1][2] that essentially do the same thing but are a bit more specialized than what you’re asking or using an older version of the blockstore / library V2 APIs.
There are definitely some people using them for specific purposes, but because the V1 libraries feature was never fully developed, it doesn’t have very widespread usage.
If I’m permitted a comment, in the past Open edX has repeatedly had some of its features replaced by rewrites that focused on adding new functionality, rather than achieving feature parity first. When such a thing happens (not only in Open edX, I hasten to point out — this happens in a lot of other projects as well), it usually leads to the “old” thing never being phased out but just falling into a state of slow terminal decay.
With that said,…
… to the best of my knowledge (please correct me if I’m wrong!) Libraries v1 was/is the only way that you can build quizzes/exams with truly randomized content from a large question bank, which I think is relevant to people.
So, how is Libraries v2 currently doing on content randomization? When I asked in Lisbon, the response was “no support in Nutmeg”, so I’m curious about how we are looking on that front for upcoming releases?
There is ongoing work on updating the V2 libraries’ functionality. Random block (LibraryContentBlock) ability to use V2 libraries feature is in progress now, you can check its PR here: https://github.com/openedx/edx-platform/pull/30615
I’m not sure, but I think it could be presented in the Olive release)
Agree with you. But I’m afraid it could become a huge problem if not deprecated in time like it was with the old mongo staff
When such a thing happens (not only in Open edX, I hasten to point out — this happens in a lot of other projects as well), it usually leads to the “old” thing never being phased out but just falling into a state of slow terminal decay.