8143796b26
Update documentation, comments, and docstrings throughout the codebase to reflect the migration from setup.py to pyproject.toml: - Transformer class docstrings: changed to reference "entry point name in the package configuration" for better future-proofing - Block structure module docs: updated to reference pyproject.toml - Test file comments: updated entry point references - Config files (tox.ini, pytest.ini): updated references - Documentation (extension_points.rst, course apps ADRs): updated to reference pyproject.toml with inclusive language for external packages - Requirements documentation (github.in): updated with inclusive language - edxmako README: modernized install command to use pip install Historical ADRs and references to external packages that may still use setup.py were intentionally left unchanged or updated with inclusive language acknowledging both pyproject.toml and setup.py. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
90 lines
3.7 KiB
Plaintext
90 lines
3.7 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 package name defined in the repo's pyproject.toml
|
|
# (or setup.py for older packages).
|
|
#
|
|
# * 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 defined in the repo's pyproject.toml
|
|
# (or setup.py for older packages). 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
|
|
# the package's build configuration, 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
|