6a8cdeeb43
This commit upgrades the version of the lti-consumer-xblock library from version 4.5.0 to version 5.0.0. This new version contains breaking changes to the public Python API published by the library, but it mainly contains code refactors that decouple the LtiConsumerXBlock.location field from the basic LTI 1.3 launches. LTI 1.3 launches should continue to work unaltered. The only course staff or instructor facing changes are described below. The access token and keyset URLs displayed in Studio have changed in format. The old format was: Access Token URL: https://courses.edx.org/api/lti_consumer/v1/token/block-v1:edX+999+2022Q3+type@lti_consumer+block@714c10a5e4df452da9d058788acb56be Keyset URL: https://courses.edx.org/api/lti_consumer/v1/public_keysets/block-v1:edX+999+2022Q3+type@lti_consumer+block@714c10a5e4df452da9d058788acb56be The new format is: Access Token URL: https://courses.edx.org/api/lti_consumer/v1/token/c3f6af60-dbf2-4f85-8974-4ff870068d43 Keyset URL: https://courses.edx.org/api/lti_consumer/v1/public_keysets/c3f6af60-dbf2-4f85-8974-4ff870068d43 The difference is in the slug at the end of the URL. In the old format, the slug was the UsageKey of the XBlock associated with the LTI integration. In the new format, the slug is the config_id of the LtiConfiguration associated with the LTI integration. This is an iterative step toward decoupling the access_token_endpoint and the public_keyset_endpoint views from the XBlock location field. The XBlock location field appears as the usage_key parameter to both views. We cannot simply remove the usage_key parameter from the views, because existing LTI 1.3 integrations may have been created using the old format, and we need to maintain backwards compatibility. This change, however, prevents new integrations from being created that are coupled to the XBlock. In the future, we may address integrations that use the old format to fully decouple the XBlock from the views.
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/openedx/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.