From 0ef86fc2a0c8129ddd3695266897c5095c9df3d1 Mon Sep 17 00:00:00 2001 From: Emad Rad Date: Wed, 29 Nov 2023 11:23:29 +0330 Subject: [PATCH 1/2] docs: add more clarity to debugging section --- docs/dev.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/dev.rst b/docs/dev.rst index d6d2851..9732df8 100644 --- a/docs/dev.rst +++ b/docs/dev.rst @@ -86,7 +86,10 @@ Finally, the platform can also be started back up with ``launch``. It will take Debugging with breakpoints -------------------------- -To debug a local edx-platform repository, add a `python breakpoint `__ with ``breakpoint()`` anywhere in the code. Then, attach to the applicable service's container by running ``start`` (without ``-d``) followed by the service's name:: +To debug a local edx-platform repository, first, start development in detached mode (with ``-d``), add a `python breakpoint `__ with ``breakpoint()`` anywhere in the code. Then, attach to the applicable service's container by running ``start`` (without ``-d``) followed by the service's name:: + + # Start in detached mode: + tutor dev start -d # Debugging LMS: tutor dev start lms From 8681ecade3fee752ee8a458ada9b8c81b76e237e Mon Sep 17 00:00:00 2001 From: Emad Rad Date: Wed, 29 Nov 2023 11:38:18 +0330 Subject: [PATCH 2/2] chore: fixed typos --- docs/configuration.rst | 6 +++--- docs/dev.rst | 2 +- docs/intro.rst | 2 +- docs/tutorials/plugin.rst | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/configuration.rst b/docs/configuration.rst index c8e4139..2efd180 100644 --- a/docs/configuration.rst +++ b/docs/configuration.rst @@ -63,13 +63,13 @@ This configuration parameter defines the name of the Docker image to run for the - ``DOCKER_IMAGE_OPENEDX_DEV`` (default: ``"openedx-dev:{{ TUTOR_VERSION }}"``) -This configuration paramater defines the name of the Docker image to run the development version of the lms and cms containers. By default, the Docker image tag matches the Tutor version it was built with. +This configuration parameter defines the name of the Docker image to run the development version of the lms and cms containers. By default, the Docker image tag matches the Tutor version it was built with. .. https://hub.docker.com/r/devture/exim-relay/tags - ``DOCKER_IMAGE_CADDY`` (default: ``"docker.io/caddy:2.6.2"``) -This configuration paramater defines which Caddy Docker image to use. +This configuration parameter defines which Caddy Docker image to use. - ``DOCKER_IMAGE_ELASTICSEARCH`` (default: ``"docker.io/elasticsearch:7.17.9"``) @@ -99,7 +99,7 @@ This configuration parameter defines which Simple Mail Transfer Protocol (SMTP) - ``DOCKER_IMAGE_PERMISSIONS`` (default: ``"{{ DOCKER_REGISTRY }}overhangio/openedx-permissions:{{ TUTOR_VERSION }}"``) -This configuration parameter defines the Docker image to be used for setting file permissions. The default image sets all containers to be run as unpriveleged users. +This configuration parameter defines the Docker image to be used for setting file permissions. The default image sets all containers to be run as unprivileged users. Custom registry *************** diff --git a/docs/dev.rst b/docs/dev.rst index 9732df8..3f951a0 100644 --- a/docs/dev.rst +++ b/docs/dev.rst @@ -183,7 +183,7 @@ To check whether you have used the correct syntax, you should run ``tutor mounts $ tutor mounts add /path/to/edx-platform $ tutor mounts list - - name: /home/data/regis/projets/overhang/repos/edx/edx-platform + - name: /path/to/edx-platform build_mounts: - image: openedx context: edx-platform diff --git a/docs/intro.rst b/docs/intro.rst index ba6889e..c612016 100644 --- a/docs/intro.rst +++ b/docs/intro.rst @@ -129,7 +129,7 @@ Many commands can be further parameterized to specify their target and options, tutor k8s logs mysql # View logs of MySQL in Kubernetes-managed deployment. tutor dev logs lms --tail 10 # View ten lines of logs of the LMS container in development mode. -And that's it! You do not need to understand Tutor's entire command-line interface to get started. Using the ``--help`` option that's availble on every command, it is easy to learn as you go. For an in-depth guide, you can also explore the `CLI Reference `_. +And that's it! You do not need to understand Tutor's entire command-line interface to get started. Using the ``--help`` option that's available on every command, it is easy to learn as you go. For an in-depth guide, you can also explore the `CLI Reference `_. I'm ready, where do I start? ---------------------------- diff --git a/docs/tutorials/plugin.rst b/docs/tutorials/plugin.rst index 3b50448..55d91bd 100644 --- a/docs/tutorials/plugin.rst +++ b/docs/tutorials/plugin.rst @@ -4,7 +4,7 @@ Creating a Tutor plugin ======================= -Tutor plugins are the offically recommended way of customizing the behaviour of Tutor. If Tutor does not do things the way you want, then your first reaction should *not* be to fork Tutor, but instead to figure out whether you can create a plugin that will allow you to achieve what you want. +Tutor plugins are the officially recommended way of customizing the behaviour of Tutor. If Tutor does not do things the way you want, then your first reaction should *not* be to fork Tutor, but instead to figure out whether you can create a plugin that will allow you to achieve what you want. You may be thinking that creating a plugin might be overkill for your use case. It's almost certainly not! The stable plugin API guarantees that your changes will keep working even after you upgrade from one major release to the next, with little to no extra work. Also, it allows you to distribute your changes to other users. @@ -104,7 +104,7 @@ Modifying configuration In the previous section you've learned how to add custom content to the Tutor templates. Now we'll see how to modify the Tutor configuration. Configuration settings can be specified in three ways: -1. "unique" settings that need to be generated or user-specified, and then preserved in config.yml: such settings do not have reasonable defaults for all users. Examples of such setttings include passwords and secret keys, which should be different for every user. +1. "unique" settings that need to be generated or user-specified, and then preserved in config.yml: such settings do not have reasonable defaults for all users. Examples of such settings include passwords and secret keys, which should be different for every user. 2. "default" settings have static fallback values. They are only stored in config.yml when they are modified by users. Most settings belong in this category. 3. "override" settings modify configuration from Tutor core or from other plugins. These will be removed and restored to their default values when the plugin is disabled.