Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build edx-platform assets without Python #31800

Open
4 of 7 tasks
Tracked by #21
kdmccormick opened this issue Feb 21, 2023 · 0 comments
Open
4 of 7 tasks
Tracked by #21

Build edx-platform assets without Python #31800

kdmccormick opened this issue Feb 21, 2023 · 0 comments
Assignees
Labels
epic Large unit of work, consisting of multiple tasks

Comments

@kdmccormick
Copy link
Member

kdmccormick commented Feb 21, 2023

Background

Overlaps with:

Goal

edx-platform's static assets can be built without installing a Python interpreter or any Python packages.

Benefits:

  • Better staged image builds: When building a container image for edx-platform, the build stage for assets will not need to install any Python requirements or copy in Python code. Thus, the asset build cache will not be broken due to changes to Python or Python requirements lists.
  • Saner tooling: Dropping our deprecated and/or bespoke Python frontend tools in favor of simpler, modern JS-based or shell-based tools makes the platform's build process easier to understand and maintain.

Tasks

Tasks

  1. 5 of 6
    kdmccormick
  2. 7 of 7
    kdmccormick
  3. 3 of 3
    kdmccormick
  4. create-sandbox
    kdmccormick
@kdmccormick kdmccormick self-assigned this Feb 21, 2023
@kdmccormick kdmccormick changed the title Build edx-platform assets without Python Python-free asset build Mar 19, 2023
@kdmccormick kdmccormick changed the title Python-free asset build Build edx-platform assets without Python Mar 19, 2023
@kdmccormick kdmccormick added the epic Large unit of work, consisting of multiple tasks label Mar 20, 2023
kdmccormick added a commit to kdmccormick/edx-platform that referenced this issue Jul 27, 2023
The Webpack configuration file for built-in XBlock JS used to be
generated at build time and git-ignored. It lived at
common/static/xmodule/webpack.xmodule.config.js. It was generated
because the JS that it referred to was also generated at build-time, and
the filenames of those JS modules were not static.

Now that its contents have been made entirely static [1], there is no
reason we need to continue generating this Webpack configuration file.
So, we check it into edx-platform under the name
./webpack.builtinblocks.config.js. We choose to put it in the repo's
root directory because the paths contained in the config file are
relative to the repo's root.

This allows us to behead both the xmodule/static_content.py
(`xmodule_assets`) script andthe  `process_xmodule_assets` paver task, a
major step in removing the need for Python in the edx-platform asset
build [2]. It also allows us to delete the `HTMLSnippet` class and all
associated attributes, which were exclusively used by
xmodule/static_content.py..

We leave `xmodule_assets` and  `process_xmodule_assets` in as stubs for
now in order to avoid breaking external code (like Tutor) which calls
Paver; the entire pavelib/assets.py function will be eventually removed
soon anyway [3]. Further, to avoid extraneous refactoring, we keep one
method of `HTMLSnippet` around on a few of its former subclasses:
`get_html`. This method was originally part of the XModule framework;
now, it is left over on a few classes as a simple internal helper
method.

References:
1. openedx#32480
2. openedx#31800
3. openedx#31895

Part of: openedx#32481
kdmccormick added a commit that referenced this issue Jul 27, 2023
…ts` (#32685)

The Webpack configuration file for built-in XBlock JS used to be
generated at build time and git-ignored. It lived at
common/static/xmodule/webpack.xmodule.config.js. It was generated
because the JS that it referred to was also generated at build-time, and
the filenames of those JS modules were not static.

Now that its contents have been made entirely static [1], there is no
reason we need to continue generating this Webpack configuration file.
So, we check it into edx-platform under the name
./webpack.builtinblocks.config.js. We choose to put it in the repo's
root directory because the paths contained in the config file are
relative to the repo's root.

This allows us to behead both the xmodule/static_content.py
(`xmodule_assets`) script andthe  `process_xmodule_assets` paver task, a
major step in removing the need for Python in the edx-platform asset
build [2]. It also allows us to delete the `HTMLSnippet` class and all
associated attributes, which were exclusively used by
xmodule/static_content.py..

We leave `xmodule_assets` and  `process_xmodule_assets` in as stubs for
now in order to avoid breaking external code (like Tutor) which calls
Paver; the entire pavelib/assets.py function will be eventually removed
soon anyway [3]. Further, to avoid extraneous refactoring, we keep one
method of `HTMLSnippet` around on a few of its former subclasses:
`get_html`. This method was originally part of the XModule framework;
now, it is left over on a few classes as a simple internal helper
method.

References:
1. #32480
2. #31800
3. #31895

Part of: #32481
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Large unit of work, consisting of multiple tasks
Projects
No open projects
Development

No branches or pull requests

1 participant