2023-08-14 DevEx Meetup Notes

Aug 14, 2023


Please be advised: DevExp Working Group meetings are recorded.

Link: (posted after meeting)


Meeting captain: @Kyle McCormick

Notetaker: @Rebecca Graber (Deactivated)

@Diana Huang

@Jeremy Bowman (Deactivated)

Discussion topics





Start the Zoom recording!


Scheduled Topics / Demos

  • @Kyle McCormick - Switch to Google Meet going forward?

    • Done decided

  • @Kyle McCormick - My schedule for the next couple months

    • Now - Sep 15: Focusing on Content Libraries V2 project. I’ll be around to help with DevX still but it won’t be my full focus.

      • Bringing Blockstore to the world at large

    • Sep 15 - Oct 1: Out on vacation

  • @Kyle McCormick - New static assets build is here – let’s optimize our Docker images!

    • Demo

      • Building sometimes garbage collects image layers, so you may end up rebuilding when you thought you were already built

      • paver update-assets replaced with the scripts at the top of edx-platform/package.json

        • eg: npm run webpack, npm run compile-sass, npm build to do both

        • tutor dev run lms npm run build-dev

          • runs webpack & compile-sass

          • better output from compile-sass

          • note: fed-bom is working on upgrading webpack in edx-platform which might speed things up even more

        • no python requirements for the build except click and lib-sass, which does still take a while to install

          • that’s the way it is until we upgrade lib-sass or get all the sass out of edx-platform

            • this requires getting everything into MFEs, which is 1-2 years out

            • no current plan to upgrade lib-sass because it’s hard

            • lib-sass is also blocking the python 3.10-11 upgrade. 3.8 hits EOL in October 2024

            • plan: get studio authoring and preview into MFEs, then upgrade lib-sass (it will be easier without the studio authoring and preview stuff)

          • click is just nicer than bash for argument parsing

        • tutor requirements folder is where you add special requirements via private.txt

          • rebuilding the dev images after doing this is slow and annoying (6-7 minutes because it rebuild static assets)

          • Not anymore! static assets get cached . Down to 90s

          • dev mode does not collect static assets, we still do it in prod

    • Q (Becca): What do you mean by not use this in production yet?

      • We should not switch Ansible and/or Tutor build to use the npm command instead of paver until more beta testing has been done

    • Q (Regis): What is worrying you about putting this in prod?

      • A: Kyle went on vacation 2 days after it was finished and hasn’t had a chance to really use it yet. May put it into tutor-nightly for more testing

    • Q (Jeremy): Is there any subset of edx-platform where porting to an MFE will remove the bulk of the sass?

      • Course-preview

      • Studio authoring

    • Q (Becca): Hacking on edx-platform and a dependency at the same time? Why do we have to rebuild the image in Tutor and not in devstack?

      • Bind-mount dependency folder into the same container

      • this is not as easy in Tutor as devstack

      • to add the dependency to the container, it’s most convenient to have it inside edx-platform and modify the requirements file

      • In devstack, running pip install -e is an ephemeral change to the lms container. if you bring devstack down and up, that change is lost. In Tutor, you make the change to the image itself, so changes stay when you bring up and down

      • Could conceivably make a plugin to bind-mount the necessary requirements directories. This may go into the tutor project.

  • @Kyle McCormick / @Régis B. - Tutor MFE dev performance improvements?

    • (Potential demo)

    • Only one MFE container in dev unless you bind-mount another MFE

    • Problem: it was difficult to run openedx in dev mode in Palm due to the number of MFEs. Each development MFE was running with npm run start which has hot reload, but slows down everything and eats the CPU

    • Solution: Run all MFEs using a static webserver like we do in prod, in a single container.

      • How to detect which MFEs still need hot reloading? The MFEs will be bind-mounted in.

      • For those MFEs, run a separate container that still runs npm run start

      • May require a rebuild since you’re also mounting node-modules

      • Was pretty easy to implement since we do run-time configuration for MFEs

      • MFE container listens to many different ports in development

Cross Pollination

  • Tools/features/opportunities

  • Tips and tricks

  • Roadmap news




  • Each challenge should have a follow up action.

  • If you have an idea for follow up actions, add it.

  • Or if you aren’t sure, leave it blank.

  • We’ll discuss all actions either way.



  • DevExp wins!

Regis made many Dockerfile improvements which made things faster and more clear!

After Kyle’s work we are well on our way to making image building way faster, and it will get faster with all the frontend code we remove!

Suggested Action Items

Last Time:

@Kyle McCormick review Jeremy’s doc, add details about Tutor changes in Palm
@Rebecca Graber (Deactivated) to follow up with BTR about making sure everyone knows about the mysql8 upgrade (EOL 10/21)
@Rebecca Graber (Deactivated) to talk to @Kyle McCormick about how to funnel people to the correct slack channels

This Time:

@Rebecca Graber (Deactivated) to check Tutor on ARM again
@Kyle McCormick switch invite to Meet
@Kyle McCormick @Régis B. work on tutor dockerfile & automatic mounting of custom packages

After the meeting…

  • Make an agenda for next time (tip: copy this page).

  • Axim: Paste in the Zoom link once it’s ready.

  • Paste these notes and next week’s agenda in #wg-developer-experience