# 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