The "imp" module is deprecated and should be replaced by "importlib". As
a consequence, loading the django settings used to raise deprecation
warnings:
DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
It should be noted that python 3.5.1 ships with an older release of
distutils which still relies on the imp module. Thus, users of python
3.5.1 (for instance: edx.org developers) will continue to see the
deprecation warning for some time, despite this patch. We suggest
upgrading to python 3.5.9.
This addresses part of CRI-196.
We shouldn't be explicitly setting this here. It's already set in all of
our override files and not everyone who wants to use production.py wants
to use SES so we shouldn't hardcode it here.
Also move the other settings to above the config loading so that all
config can be overridden by the config file.
add improved re-write for course updates
add improved re-write for course updates
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
Now that we autoload most keys directly from the yaml file into the
settings context. We don't need boilerplate of the form:
KEY = ENV_TOKENS.get('KEY', KEY)
KEY = AUTH_TOKENS.get('KEY', KEY)
which tries to get the value of KEY from the config file but if it's not
there it pulls it from the defaults found in common.py
The studio tabs page had a race condition when loading many static tabs.
The result was that those tabs couldn't be deleted. By requiring the
`xmodule` module, we force the EditTabsFactory to load
XBlockToXModuleShim before it's needed.
The upgrade to Django 2.2 has caused a spike in production logging due to RemovedInDjango30Warning deprecation warnings. For now, turn off logging of DeprecationWarning, ImportWarning, and PendingDeprecationWarning whenever we're using WSGI (they'll continue to be logged in devstack). We may eventually want this behind an easily flipped toggle, but for now just remove it to get this resolved quickly.
This should allow us to remove all the boilerplate code in this file
where a name is pulled from the config dict and put into the top level
namespace of the settings module.
We do this first so that any logic that adds more complex or dynamic
keys will still run and is safe.
Now that this is here we can start removing any simple boilerplate.
1. Created a new celery queue with key `SOFTWARE_SECURE_VERIFICATION_ROUTING_KEY`.
2. Added a celery task with retry logic.
3. sorted imports with isort.
4. Changed deprecated `log.warn` => `log.warning`.
Before Django 2.1, the dict was being stringified as `{'name': 'file.txt'}`
(note the single quotes) and producing a JSON parse error in
https://github.com/edx/edx-platform/blob/9cf2f9f/cms/djangoapps/contentstore/views/assets.py#L541
which was then converted to a 400 error. However, in Django 2.1,
django.test.client starts JSON-encoding request bodies when an appropriate
content-type is set:
https://github.com/django/django/compare/2.0.8..2.1#diff-97160f50594424a40f2621d5a3c581ccR320
This results in the JSON parse succeeding, and the expected error never
occurs; instead, there is a KeyError when the `locked` attribute is
missing from the dict.
For now, removing the test, since it is blocking Django 2 upgrade work,
and we need to get off of (unsupported) Django 1.11 ASAP.
We should probably repair and restore this test, but it is likely that
we'll want to change the code it is testing first, since that code is
insufficiently defensive and handles both multipart form data and JSON
without properly checking which kind it is dealing with, as well as
assuming too much about what keys are present in the JSON.
I've filed ARCHBOM-1090 for this followup work.
Background: I use private.py a lot in my devstack for my private configurations. But issues are raised when I need to change/override a setting that is defined in devstack_docker.py file. Since that file's contents are loaded after private.py, my private.py is useless against the settings in devstack_docker.py.
Description: Now that the devstack is dockerized, I think it makes more sense to import the private.py in the devstack_docker.py files i.e. at the end of configuration files hierarchy.
