Is there export and import of libraries (AI Library Builder)?

abylaikhan.suev.02 · June 18, 2025, 12:18pm

Hello. I had an idea to create a tool for generating a library with questions. I think it’s quite useful and much more practical than the AI Course Builder (although that tool is also very cool).

braden · June 18, 2025, 5:35pm

The new libraries (beta) features do not yet have an import-export feature, but it’s being planned at the moment, and I believe the goal is to have some version of it working in the next release (“Ulmo”). CC @jmakowski

In the meantime, you can use the Library Blocks API and XBlock API to generate content from python, move it around among libraries, and export it to OLX.

dave · June 18, 2025, 8:56pm

FWIW, the work to add import/export functionality to beta libraries is kicking off next week Wednesday, starting with this ticket:

github.com/openedx/openedx-learning

Implement dump/load format for libraries

opened 06:37PM - 07 Jun 25 UTC

ormsbee

arch

## Requirements * Should be able to copy a library to a new instance so that it… can be hooked up with a course that uses it. * Human readable * Extensible, i.e. new apps/models should be able to hook into it * Useful for debugging purposes ## Non-requirements * No need for partial import. This is "wipe everything and make this the new state of things". This is also not going to be permission aware--it's an admin task. Weirdly enough, this might be a really harsh way to prune a library without breaking dependent content, though it would break all ownership information, unless we add support for that later. ## Tentative Task Breakdown (WIP) - [ ] Create dump management command as part of Learning Core, i.e. openedx-learning. This would just dump metadata about the top level learning package into a .toml file in a zip archive. - [ ] Create restore management command as part of Learning Core, i.e. openedx-learning. This would just load metadata about the top level learning package into a .toml file in a zip archive. - [ ] Add support for exporting PublishableEntities - [ ] Add support for versions export, including draft and published pointers - [ ] Add support for components, including files - [ ] Add support for units (and containers as part of that) - [ ] Refactor to accommodate arbitrary extension - [ ] Add support for subsections - [ ] Add support for sections ## Initial thoughts ### TOML for Metadata As a file format, TOML has some useful attributes: 1. Table formatting makes it easy to break things into sections by app/model. 2. It supports comments, so we can annotate things that are useful as debug data on export, but that might not apply to import, e.g. derived data, creation times, etc. YAML is another possibility. YAML would scale better to deeply nested structures, and we could make use of separate documents in the same file to separate apps/models that want to attach data. I prefer to start with TOML because it's simpler and won't do weird auto-parsing, e.g. "owner: edx" works fine, but "owner: 2u" dies because it auto-casts the former to a string but the latter looks like it's a failed number to the parser; or "country: US" works fine as a string but "country: NO" turns into a boolean. ### Zip as the archive format Zip is better supported and more understandable for the average user. The downside is that for repeated assets, Zip is likely to be less efficient overall, particularly if we get many versions of the same component with matching assets. That's not an intended use case for this though, since we only plan to capture draft + publishing versions + whatever versions are pinned by containers, whenever we start supporting that as a feature. We can do all the operations inside a Zip file directly instead of writing a bunch of files and zipping it later. ### Structure Let's say we have a library `lib:Axim:2025-06-04` An example hierarchy could be: ``` Axim2025-06-04.zip └── Axim2025-06-04 ├── collections │ └── interesting-things.toml ├── entities │ ├── fun-unit-36c349 │ │ └── versions │ │ └── 1.toml │ ├── fun-unit-36c349.toml │ └── xblock.v1 │ └── html │ ├── i-dont-like-the-sidebar-aa1645ade4a7 │ │ └── versions │ │ ├── 3 │ │ │ ├── block.xml │ │ │ └── static │ │ └── 3.toml │ └── i-dont-like-the-sidebar-aa1645ade4a7.toml └── library.toml ``` Some notes: 1. Components have colons in their publishable entity keys, so we make those into directory breaks instead. 2. Versions are currently broken out into their own TOML files in this scenario, but they could also be folded into the TOML file of the entities themselves as a separate section. The TOML files would be broken up by model/app, like this for a unit version: ```toml [version] title = "Fun Unit" uuid = "a6f97e8e-98b8-4cd9-9dcc-5a6744110401" [container-version] children = [ "xblock.v1:html:i-dont-like-the-sidebar-aa1645ade4a7", # We can mix types in a TOML array, so we can keep the string for the simple # common use case, but later add entries that are inline tables if we need # to override things, like: # {"key" = "xblock.v1:html:i-dont-like-the-sidebar-aa1645ade4a7", "version_num" = 2} ] [unit-version] # we wouldn't actually do this, but I'm making an example here... graded = true ``` Future extensions would add their own tables here. The actual OLX and static assets for a component go in a subdirectory for the version. A quick sketch with some comments added: [Axim2025-06-04.zip](https://github.com/user-attachments/files/20640374/Axim2025-06-04.zip)

If you’re just starting down this road, the part that I would recommend focusing on is the accurate generation of problem OLX content. In the past, I’ve seen LLMs generate OLX that looks plausible at first glance, but turned out to be malformed in subtle ways.

Zachary_Trabookis · September 29, 2025, 1:27pm

@braden @jmakowski @dave
Is this Library Content (Beta) export/import functionality scheduled to be released with Ulmo?

We currently use Grove to deploy multiple instances of Open edX. We’ve set up our courses to be developed on one instance and then port content over to another instance to release to our customers. Once this new Library Content (Beta) export/import functionality exists, we should be able to export library components/Units from one Grove instance to the other.

Will we have to re-add/re-link the updated Library Content (Beta) course component to the destination Grove instance course to that instance library to pull in the library updates to the course? It seems like this could be an issue, and maybe we should just develop our courses on the same system where the Library Content (Beta) is going to receive its updates and already be linked into the course(s).

I’m guessing that the courses reference the library by the lib:ORG:NAME identifier so this should probably work when ported over to the destination Grove instance Library Content (Beta) and referenced in the courses.

Topic		Replies	Views
How to Import multiple Courses/Libraries? Authoring	20	2925	May 7, 2022
Contents management in Library Educators	2	731	October 20, 2021
Why deleting a library is not an option? Authoring	2	1324	August 20, 2021
How can I actually use Library content in a Course? Authoring	6	1779	May 18, 2022
Sync Library component/unit updates to multiple courses with one interface rather than going to each course and pulling down the updates Development	12	152	October 10, 2025

Is there export and import of libraries (AI Library Builder)?

Related topics