[FAL-2198] Django 3.2 support

[mtyaka]

This updates the tests so that they run in an environment with Django 3.2.
It also fixes a few deprecation warnings.

Note: this also incorporates updates from #332.

Test instructions:

1. Verify that the automated tests succeed on python3.8 / Django 3.2
2. Verify that the XBlock works correctly in xblock-sdk with Django 3.2

[xitij2000]

Looks good! just one minor issue I see.

I'm testing this right now.

[xitij2000]

I think the original names were what are used for edx-platform so we should stay consistent with that: https://github.com/edx/edx-platform/blob/0935b5c51fa4115caa6d6d98b0ef65fea4fcdec1/conf/locale/config.yaml#L9-L91

[mtyaka]

@xitij2000 Django3.2 refused to start with the original names. It would throw this error.

I looked at the LANGUAGES setting in edx-platform and they do use the django3.2 compatible names, so I thought it was ok to change this, but I don't really know how translations work with this XBlock.

I didn't test whether translations are working - I don't know if that's possible to do inside xblock-sdk.

[xitij2000]

I don't think it's possible with xblock-sdk, but I've done it a lot, so I'll have a quick look with one of the affected languages.

[xitij2000]

es-419:

ja-jp:

Seems to be working :-)

[mtyaka]

Great, thanks a lot for checking :)

[xitij2000]

👍
Currently, PB_LANGUAGE_JS_DIRECTORY_MAP is imported from settings and it imports workbench.setting which isn't available on edx-platform. So we should move PB_LANGUAGE_JS_DIRECTORY_MAP to a place where it can be imported from both places, without importing settings.
Other than that, there is one more issue I see:

problem-builder-styling-issue.mp4

The styling is a bit off. However, since there have been a lot of changes in the platform recently, we can leave this to a separate task. It might also just be an issue with the master release and not the current release.

• I tested this: (describe what you tested)
• I read through the code
• [na] I checked for accessibility issues (no changes)
• Includes documentation
• [na] I made sure any change in configuration variables is reflected in the corresponding client's configuration-secure repository.

[saksham115]

@mtyaka when I am running make requirements inside the xblock-sdk submodule, my django version is reverted back to 2.2

Am i missing something? My submodule version that is being shown is c1384a5b6e058a5f15b231013414f859e9924008

[mtyaka]

when I am running make requirements inside the xblock-sdk submodule, my django version is reverted back to 2.2

@saksham115 Yeah, that's a bit of a mess currently. While xblock-sdk does support Django3.2 via tox, it still defaults to 2.2. You can try manually force-installing Django3.2 in your virtualenv (replacing the 2.2 installation).

[saksham115]

when I am running make requirements inside the xblock-sdk submodule, my django version is reverted back to 2.2

@saksham115 Yeah, that's a bit of a mess currently. While xblock-sdk does support Django3.2 via tox, it still defaults to 2.2. You can try manually force-installing Django3.2 in your virtualenv (replacing the 2.2 installation).

Yeah, that's what I did later (manually installing Django3.2). Cool, glad to know that was the correct approach.

[saksham115]

👍🏻

Did the steps mentioned in the testing instructions, with force-installing Django3.2 after the sdk installation

• I tested this, as per the testing methods and the steps defined in README
• I read through the code
• Includes documentation

One small suggestion (Don't know if it fits here or not):

• Maybe include the, git submodule update --init step in the readme to fetch the xblock-sdk (Not a blocker for merge)