Files
edx-platform/requirements
michaelroytman 5d5fce2949 fix: missing exception details in xblock-lti-consumer logs
This commit updates the version of the lti-consumer-xblock from 4.3.2 to 4.3.3. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.

The error handler in LtiConsumerXBlock.lti_1p3_launch_callback logs a warning when a select set of exceptions are handled. That log does not contain useful information about the nature of the exception, because the exceptions were not being instantiated with error messages. The try...catch is a large block that contains code that can raise a multitude of errors, so these changes will enable better debugging.

This commit:
* adds helpful messages to the raised exceptions.
* adds the "exc_info=True" argument to include the stack trace of the handled exception.
* adds ValueError and TypeError to the list of handled exceptions, because the code can raise exceptions of these types.
2022-08-03 08:17:25 -04:00
..
2022-07-28 15:56:03 +05:00
2018-04-13 14:10:40 -04:00
2022-05-24 15:15:00 +05:00

Requirements/dependencies
=========================

These directories specify the Python (and system) dependencies for the LMS and Studio.

- ``edx`` contains the normal Python requirements files
- ``edx-sandbox`` contains the requirements files for Codejail
- ``constraints.txt`` is shared between the two

(In a normal `OEP-18`_-compliant repository, the ``*.in`` and ``*.txt`` files would be
directly in the requirements directory.)

.. _OEP-18: https://github.com/edx/open-edx-proposals/blob/master/oeps/oep-0018-bp-python-dependencies.rst

Upgrading/downgrading just one dependency
-----------------------------------------

Want to upgrade just *one* dependency without pulling in other upgrades? Here's how:

1. Change your dependency to a minimum-version constraint, e.g. ``my-dep>=1.2.3`` (or update the constraint if it already exists)
2. Run ``make compile-requirements`` to recompute dependencies with this new constraint

If you instead need to surgically *downgrade* a dependency, perhaps in order to revert a change which broke things:

1. Add an exact-match or max-version constraint to ``constraints.txt`` with a comment explaining why (and ideally a ticket or issue link)
2. Lower the minimum-version constraint, if it exists

    - Not sure if there is one? Try going on to the next step and seeing if it complains!

3. Run ``make compile-requirements``

This is considerably safer than trying to manually edit the ``*.txt`` files, which can easily result in incompatible dependency versions.