Files
edx-platform/requirements
michaelroytman efc59de056 test: add debugging log statements for user_id LtiError
This commit updates the version of the lti-consumer-xblock from 4.3.1 to 4.3.2. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.

This commit adds supplemental logging to diagnose the bug reported in MST-1540: https://2u-internal.atlassian.net/browse/MST-1540. The bug is that learners are encountering the LtiError when trying to do an LTI launch. The learners appear to be authenticated, so this error should not occur. The bug is not easily reproducible in production or development, so this supplemental logging is added to help understand the user's state when the error is raised.

The current hypothesis is that user is temporarily represented by the AnonymousUser in the request that is made when doing the LTI launch, despite the user otherwise being authenticated. Logging in Splunk suggests that this is the case, because logs are of the following form, "2022-07-22 15:10:14,214 ERROR 5067 [django.request] [user None] [ip <ip>] log.py:224 - Internal Server Error: /courses/<course_key>/xblock/<usage_key>/handler/lti_launch_handler", where the "user" is "None". This logging should prove or disprove this hypothesis and provide direction about where else to look.

This logging should be removed once MST-1540 is resolved.
2022-07-22 12:41:23 -04: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.