Instead of going up the stacktrace to find the module names of waffle
flags and switches, we manually pass the module __name__ whenever the
flag is created. This is similar to `logging.getLogger(__name__)`
standard behaviour.
As the waffle classes are used outside of edx-platform, we make the new
module_name argument an optional keyword argument. This will change once
we pull waffle_utils outside of edx-platform.
Note that the module name is normally only required to view the list of
existing waffle flags and switches. The module name should not be
necessary to verify if a flag is enabled. Thus, maybe it would make
sense to create a `add` class methor similar to:
class WaffleFlag:
@classmethod
def add(cls, namespace, flag, module):
instance = cls(namespace, flag)
cls._class_instances.add((instance, module))
These new settings files are intended to be used by the Analytics
Exporter automation managed by the DE team. The Analytics Exporter must
be able to simply clone edx-platform, install requirements, fetch
remote-config, then just run management commands without needing to run
any ansible or pull down any docker/AMI images. Since the theming app
includes a check that fails if the themes base dir cannot be found, and
that check runs on app startup, we must disable the app.
DENG-379
* Add and push Dockerfile; add decentralized devstack settings
Co-Authored-By: Diana Huang <dkh@edx.org>
Co-Authored-By: Kyle McCormick <kmccormick@edx.org>
* Remove Python requirements hack
Remove the attempted optimization to the installation of Python
package dependencies. The dependencies in edx-platform change
about three times per day, so this was of dubious value. And
because npm is run through nodeenv, which is a Python package,
the Python dependencies installation has to happen first.
* ARCHBOM-1439: Changing workdir to /edx/app/edxapp/edx-platform (#24835)
Context: The Dockerfile tries to stay in sych with legacy stuff.
In the ansible we configure the directory structure such that things
relating to the app but not in the codebase,
such as the env file wind up in /edx/app/edxapp/.
And the codebase winds up in /edx/app/edxapp/edx-platform.
I think due to accident, the dockerfile does
/edx/app/edx-platform/edx-platform instead of /edx/app/edxapp/edx-platform.
This commit tries to have Dockerfile more reflect what is currently happening in production
* Update ports for decentralized devstack ARCHBOM-1447 (#24841)
Switch from the LMS ports we've historically used for NGINX to those used for gunicorn, and fix the Studio ports to match the ones we've historically used for its gunicorn service. Also removed some leftover bits of the requirements hack.
Co-authored-by: Adam Blackwell <ablackwell@edx.org>
Co-authored-by: Diana Huang <dkh@edx.org>
Co-authored-by: jinder1s <msingh@edx.org>
Co-authored-by: Jeremy Bowman <jbowman@edx.org>
Co-authored-by: Manjinder Singh <49171515+jinder1s@users.noreply.github.com>
The LEPL dependency was triggering a lot of deprecation warnings of the
form:
venv/lib/python3.5/site-packages/lepl/matchers/support.py:497:
DeprecationWarning: inspect.getargspec() is deprecated, use
inspect.signature() instead
argspec = getargspec(func)
It turns out that LEPL was only used by the rfc6266_parser package, which
itself was only used in one place to generate utf8-compliant
Content-Disposition headers.
This issue was noticed here:
https://github.com/SWW13/python-rfc6266-parser/issues/2
Unfortunately it is quite difficult to extract LEPL from the
rfc6266-parser package.
The rfc6266-parser package (https://pypi.org/project/rfc6266-parser/) is
itself a fork of the now-unmaintained rfc6266 package
(https://pypi.org/project/rfc6266/). Thus, it became high time to get
rid of this package. The FileResponse object can appropriately set the
Content-Disposition header, and thus replace the rfc6266 functionality,
since Django 2.0: https://code.djangoproject.com/ticket/16470
In our testing, the FileResponse object correctly set the
`filename*=utf-8''` value, following the RFC. The only difference is
that it does not provide "filename" fallback value, as expressed in the
RFC: https://tools.ietf.org/html/rfc6266#appendix-D
With rfc6266_parser:
>> import rfc6266_parser
>> rfc6266_parser.build_header("my_file_é.csv", filename_compat="video_urls.csv")
b"attachment; filename=video_urls.csv; filename*=utf-8''my_file_%C3%A9.csv"
With FileResponse we have:
>> from django.http import FileResponse
>> import io
>> response = FileResponse(io.StringIO(), as_attachment=True, filename="my_file_é.csv", content_type="text/csv")
>> response.get("Content-Disposition")
"attachment; filename*=utf-8''my_file_%C3%A9.csv"
We consider that this is a sufficiently minor difference, that will
impact very few browsers.
From what I've gleaned, CONFIG_FILE (and LMS_CFG and STUDIO_CFG
environment variables) supercedes CONFIG_ROOT. There's no code anymore
that reads the value of the CONFIG_ROOT django setting, and in turn the
CONFIG_ROOT environment variable.
Tangentially related to DENG-369
It is already enabled in devstack LMS, stage LMS/Studio,
and prod LMS/Studio.
However, it is currently disabled in edge LMS/Studio,
and as far as I know, sandbox LMS/Studio as well as the
default Open edX LMS/Studio.
We would like to move towards enabling it globally by
default, and enabling it in devstack Studio would be
a first step towards that.
