70ea641c99
This commit implements a comprehensive solution for test score integration in the enhancement system along with improvements to the score rendering mechanism. Key changes include: - Add event handler for rendering blocks with edx-submissions scores - Implement event-based mechanism to render XBlocks with scoring data - Create signal handlers in handlers.py to process external grader scores - Develop specialized XBlock loader for rendering without HTTP requests - Add queue_key propagation across the submission pipeline - Register submission URLs in LMS routing configuration - Add complete docstrings to score render module for better code maintainability - Add ADR for XBlock rendering with external grader integration - Add openedx-events fork branch as a dependency in testing.in - Upgrade edx submission dependency These changes support the migration from traditional XQueue callback HTTP requests to a more robust event-based architecture, improving performance and reliability when processing submission scores. The included ADR documents the architectural decision and implementation approach for this significant improvement to the external grading workflow.
88 lines
3.6 KiB
Plaintext
88 lines
3.6 KiB
Plaintext
# This file holds all GitHub-hosted edx-platform Python dependencies.
|
|
# Such dependencies should be added here, not to kernel.in.
|
|
# That being said....
|
|
#
|
|
# ---->>> DON'T JUST ADD NEW DEPENDENCIES!!! <<<----
|
|
#
|
|
# Every new GitHub-hosted dependency slows down the edx-platform build and
|
|
# subverts our continuous dependency upgrade process. This file should
|
|
# only be added to in exceptional circumstances.
|
|
#
|
|
# "I don't have time to publish my package to PyPI" is **not** an
|
|
# acceptable excuse. You can add a GitHub Action workflow to automatically
|
|
# upload your package to PyPI with the push of a button:
|
|
#
|
|
# * Go to https://github.com/openedx/<YOUR_REPO>/actions/new
|
|
# * Find "Publish Python Package"
|
|
# * Merge the generated PR and push package.
|
|
# * You're done! Add your dependency to kernel.in, and the requirements
|
|
# bot will automatically keep it fresh in edx-platform.
|
|
#
|
|
# If you think you must add a URL to this file, read this section of OEP-18 first:
|
|
# https://docs.openedx.org/projects/openedx-proposals/en/latest/best-practices/oep-0018-bp-python-dependencies.html#installing-dependencies-from-urls
|
|
#
|
|
# If you are sure that you need to install from GitHub, then
|
|
# use this exact format:
|
|
#
|
|
# # ISSUE-LINK
|
|
# git+https://github.com/OWNER/REPO-NAME.git@TAG-OR-SHA#egg=DIST-NAME==VERSION
|
|
#
|
|
# For example:
|
|
#
|
|
# # https://github.com/openedx/foobar/issues/212
|
|
# git+https://github.com/openedx/foobar.git@v1.3.0#egg=openedx-foobar==1.3.0
|
|
#
|
|
# where:
|
|
#
|
|
# ISSUE-LINK = https://github.com/openedx/foobar/issues/212
|
|
# OWNER = openedx
|
|
# REPO-NAME = foobar
|
|
# TAG-OR-SHA = v1.3.0
|
|
# DIST-NAME = openedx-foobar
|
|
# VERSION = 1.3.0
|
|
#
|
|
# Rules to follow:
|
|
#
|
|
# * Don't leave out any of these pieces.
|
|
#
|
|
# * ISSUE-LINK points to an item in a public issue tracker. The issue
|
|
# should be in the backlog of a particular contributor or team
|
|
# who will make sure that it is resolved.
|
|
#
|
|
# * TAG-OR-SHA is the specific commit to install. It must be a git tag,
|
|
# or a git SHA commit hash. Don't use branch names here. If OWNER is
|
|
# not openedx, then it must be a SHA. If you use a SHA,
|
|
# please make sure there is a tag associated with it, so the commit can't
|
|
# be lost during rebase.
|
|
#
|
|
# * DIST-NAME is the distribution name, the same name you'd use in a
|
|
# "pip install" command. It might be different than REPO-NAME. It must
|
|
# be the same as the `name="DIST-NAME"` value in the repo's setup.py.
|
|
#
|
|
# * VERSION might not be the same as TAG-OR-SHA, but if the tag names the
|
|
# version, please make it match the VERSION, but with a "v" prefix.
|
|
# VERSION must be the same as the `version="VERSION"` value in the repo's
|
|
# setup.py. An alternative is to use 0.0 as VERSION: this forces pip to
|
|
# re-install the package each time, and can be useful when working with two
|
|
# repos before picking a version number. Don't use 0.0 on master, only for
|
|
# tight-loop work in progress.
|
|
#
|
|
# * Don't prefix the URL with "-e". That would install the package in "editable"
|
|
# mode A.K.A "development" mode, which takes longer and does not
|
|
# fully respect setup.py, making the transition back to PyPI more complex.
|
|
#
|
|
# * Organize the URL into one of the two categories below:
|
|
|
|
|
|
##############################################################################
|
|
# Release candidates being tested.
|
|
##############################################################################
|
|
|
|
# ... add dependencies here
|
|
|
|
##############################################################################
|
|
# Critical fixes for packages that are not yet available in a PyPI release.
|
|
##############################################################################
|
|
|
|
# ... add dependencies here
|