v14.0.0: upgrade to Nutmeg

- 💥 [Feature] Upgrade to Nutmeg: (by @regisb) - 💥 [Feature] Persistent grades are now enabled by default. - [Bugfix] Remove edX references from bulk emails ([issue](openedx/wg-build-test-release#100)). - [Improvement] For Tutor Nightly (and only Nightly), official plugins are now installed from their nightly branches on GitHub instead of a version range on PyPI. This will allow Nightly users to install all official plugins by running ``pip install -e ".[full]"``. - [Bugfix] Start MongoDB when running migrations, because a new data migration fails if MongoDB is not running
overhangio · Jun 9, 2022 · b01db0f · b01db0f
1 parent 57cb956
commit b01db0f
Show file tree

Hide file tree

Showing 39 changed files with 621 additions and 610 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -18,6 +18,19 @@ Every user-facing change should have an entry in this changelog. Please respect
 
 ## Unreleased
 
+## v14.0.0 (2022-06-09)
+
+- 💥[Feature] Upgrade to Nutmeg: (by @regisb)
+  - 💥[Feature] Get rid of the `dev/local bindmount` commands which were replaced since v13.2.0 by the `--mount` option.
+  - 💥[Feature] Get rid of the `dev runserver` command which was replaced since v13.2.0 by `dev start`.
+  - [Improvement] Add `-h` option, in addition to `--help`, to print CLI help.
+  - 💥[Feature] Hide a course from the `/course` search page in the LMS when the course visibility is set to "none" in the Studio. (thanks @ghassanmas!)
+  - 💥[Improvement] The `lms.env.json` and `cms.env.json` files are moved to `lms.env.yml` and `cms.env.yml`. As a consequence, plugin developers must reformat the following patches to use YAML format, and not JSON: "common-env-features", "lms-env-features", "cms-env-features", "lms-env", "cms-env", "openedx-auth".
+  - 💥[Feature] Persistent grades are now enabled by default.
+  - [Bugfix] Remove edX references from bulk emails ([issue](https://github.com/openedx/build-test-release-wg/issues/100)).
+  - [Improvement] For Tutor Nightly (and only Nightly), official plugins are now installed from their nightly branches on GitHub instead of a version range on PyPI. This will allow Nightly users to install all official plugins by running ``pip install -e ".[full]"``.
+  - [Bugfix] Start MongoDB when running migrations, because a new data migration fails if MongoDB is not running
+
 ## v13.3.1 (2022-06-06)
 
 - [Fix] Crashing celery workers in development (#681). (by @regisb)

diff --git a/docs/configuration.rst b/docs/configuration.rst
@@ -8,7 +8,7 @@ Tutor offers plenty of possibilities for platform customisation out of the box.
 a. Modifying the Tutor :ref:`configuration parameters <configuration>`.
 b. Modifying the :ref:`Open edX docker image <customise>` that runs the Open edX platform.
 
-This section does not cover :ref:`plugin development <plugins>`. For simple changes, such as modifying the ``*.env.json`` files or the edx-platform settings, *you should not fork edx-platform or tutor*! Instead, you should create a simple :ref:`plugin for Tutor <plugins_yaml>`.
+This section does not cover :ref:`plugin development <plugins>`. For simple changes, such as modifying the ``*.env.yml`` files or the edx-platform settings, *you should not fork edx-platform or tutor*! Instead, you should create a simple :ref:`plugin for Tutor <plugins_yaml>`.
 
 .. _configuration:
 
@@ -31,7 +31,7 @@ Or from the system environment::
 
     export TUTOR_PARAM1=VALUE1
 
-Once the base configuration is created or updated, the environment is automatically re-generated. The environment is the set of all files required to manage an Open edX platform: Dockerfile, ``lms.env.json``, settings files, etc. You can view the environment files in the ``env`` folder::
+Once the base configuration is created or updated, the environment is automatically re-generated. The environment is the set of all files required to manage an Open edX platform: Dockerfile, ``lms.env.yml``, settings files, etc. You can view the environment files in the ``env`` folder::
 
     ls "$(tutor config printroot)/env"
 

diff --git a/docs/dev.rst b/docs/dev.rst
@@ -152,23 +152,8 @@ Then, bind-mount that folder back in the container with the ``--mount`` option (
 
 You can then edit the files in ``~/venv`` on your local filesystem and see the changes live in your container.
 
-Bind-mount from the "volumes/" directory
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. warning:: Bind-mounting volumes with the ``bindmount`` command is no longer the default, recommended way of bind-mounting volumes from the host. Instead, see the :ref:`mount option <mount_option>` and the ``tutor dev/local copyfrom`` commands.
-
-Tutor makes it easy to create a bind-mount from an existing container. First, copy the contents of a container directory with the ``bindmount`` command. For instance, to copy the virtual environment of the "lms" container::
-
-    tutor dev bindmount lms /openedx/venv
-
-This command recursively copies the contents of the ``/opendedx/venv`` directory to ``$(tutor config printroot)/volumes/venv``. The code of any Python dependency can then be edited -- for instance, you can then add a ``import ipdb; ipdb.set_trace()`` statement for step-by-step debugging, or implement a custom feature.
-
-Then, bind-mount the directory back in the container with the ``--mount`` option::
-
-		tutor dev start --mount=lms:$(tutor config printroot)/volumes/venv:/openedx/venv lms
-
 .. note::
-    The ``bindmount`` command and the ``--mount=...`` option syntax are available both for the ``tutor local`` and ``tutor dev`` commands.
+    The ``--mount=...`` option syntax is available both for the ``tutor local`` and ``tutor dev`` commands.
 
 Manual bind-mount to any directory
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

diff --git a/docs/install.rst b/docs/install.rst
@@ -121,11 +121,11 @@ Major Open edX releases are published twice a year, in June and December, by the
 4. Test the new release in a sandboxed environment.
 5. If you are running edx-platform, or some other repository from a custom branch, then you should rebase (and test) your changes on top of the latest release tag (see :ref:`edx_platform_fork`).
 
-The process for upgrading from one major release to the next works similarly to any other upgrade, with the ``quickstart`` command (see above). The single difference is that if the ``quickstart`` command detects that your tutor environment was generated with an older release, it will perform a few release-specific upgrade steps. These extra upgrade steps will be performed just once. But they will be ignored if you updated your local environment (for instance: with ``tutor config save``) before running ``quickstart``. This situation typically occurs if you need to re-build some Docker images (see above). In such a case, you should make use of the ``upgrade`` command. For instance, to upgrade a local installation from Lilac to Maple and rebuild some Docker images, run::
+The process for upgrading from one major release to the next works similarly to any other upgrade, with the ``quickstart`` command (see above). The single difference is that if the ``quickstart`` command detects that your tutor environment was generated with an older release, it will perform a few release-specific upgrade steps. These extra upgrade steps will be performed just once. But they will be ignored if you updated your local environment (for instance: with ``tutor config save``) before running ``quickstart``. This situation typically occurs if you need to re-build some Docker images (see above). In such a case, you should make use of the ``upgrade`` command. For instance, to upgrade a local installation from Maple to Nutmeg and rebuild some Docker images, run::
 
     tutor config save
     tutor images build all # list the images that should be rebuilt here
-    tutor local upgrade --from=lilac
+    tutor local upgrade --from=maple
     tutor local quickstart
 
 .. _autocomplete:

diff --git a/docs/plugins/intro.rst b/docs/plugins/intro.rst
@@ -4,7 +4,7 @@
 Introduction
 ============
 
-Tutor comes with a plugin system that allows anyone to customise the deployment of an Open edX platform very easily. The vision behind this plugin system is that users should not have to fork the Tutor repository to customise their deployments. For instance, if you have created a new application that integrates with Open edX, you should not have to describe how to manually patch the platform settings, ``urls.py`` or ``*.env.json`` files. Instead, you can create a "tutor-myapp" plugin for Tutor. Then, users will start using your application in three simple steps::
+Tutor comes with a plugin system that allows anyone to customise the deployment of an Open edX platform very easily. The vision behind this plugin system is that users should not have to fork the Tutor repository to customise their deployments. For instance, if you have created a new application that integrates with Open edX, you should not have to describe how to manually patch the platform settings, ``urls.py`` or ``*.env.yml`` files. Instead, you can create a "tutor-myapp" plugin for Tutor. Then, users will start using your application in three simple steps::
 
     # 1) Install the plugin
     pip install tutor-myapp
@@ -31,6 +31,20 @@ After enabling or disabling a plugin, the environment should be re-generated wit
 
     tutor config save
 
+
+Index management::
+
+    # List all plugins from the stored indices
+    tutor plugins index list
+    # Show a particular plugin
+    tutor plugins show ecommerce
+    # Install a plugin
+    tutor plugins install ecommerce
+    # Add a new index stored in a remote location (or a local path)
+    tutor plugins index add https://...
+    # Remove an existing index
+    tutor plugins index remove https://...
+
 The full plugins CLI is described in the :ref:`reference documentation <cli_plugins>`.
 
 .. _existing_plugins:

diff --git a/docs/plugins/v0/api.rst b/docs/plugins/v0/api.rst
@@ -189,9 +189,10 @@ Example::
     import click
     from tutor import config as tutor_config
 
-    @click.command(help="I'm a plugin command")
+    @click.command(context_settings={"help_option_names": ["-h", "--help"]})
     @click.pass_obj
     def command(context):
+        """"I'm a plugin command"""
         config = tutor_config.load(context.root)
         lms_host = config["LMS_HOST"]
         click.echo("Hello from myplugin!")
@@ -207,12 +208,14 @@ You can even define subcommands by creating `command groups <https://click.palle
 
     import click
 
-    @click.group(help="I'm a plugin command group")
+    @click.group(context_settings={"help_option_names": ["-h", "--help"]})
     def command():
+        """I'm a plugin command group"""
         pass
 
-    @command.command(help="I'm a plugin subcommand")
+    @command.command()
     def dosomething():
+        """I'm a plugin subcommand"""
         click.echo("This subcommand is awesome")
 
 This would allow any user to see your sub-commands::

diff --git a/docs/reference/patches.rst b/docs/reference/patches.rst
@@ -53,21 +53,21 @@ File: ``apps/caddy/Caddyfile``
 ``cms-env``
 ===========
 
-File: ``apps/openedx/config/cms.env.json``
+File: ``apps/openedx/config/cms.env.yml``
 
 .. patch:: cms-env-features
 
 ``cms-env-features``
 ====================
 
-File: ``apps/openedx/config/cms.env.json``
+File: ``apps/openedx/config/cms.env.yml``
 
 .. patch:: common-env-features
 
 ``common-env-features``
 =======================
 
-Files: ``apps/openedx/config/cms.env.json``, ``apps/openedx/config/lms.env.json``
+Files: ``apps/openedx/config/cms.env.yml``, ``apps/openedx/config/lms.env.yml``
 
 .. patch:: dev-docker-compose-jobs-services
 
@@ -137,14 +137,14 @@ File: ``kustomization.yml``
 ``lms-env``
 ===========
 
-File: ``apps/openedx/config/lms.env.json``
+File: ``apps/openedx/config/lms.env.yml``
 
 .. patch:: lms-env-features
 
 ``lms-env-features``
 ====================
 
-File: ``apps/openedx/config/lms.env.json``
+File: ``apps/openedx/config/lms.env.yml``
 
 .. patch:: local-docker-compose-caddy-aliases
 
@@ -200,7 +200,7 @@ File: ``local/docker-compose.yml``
 ``openedx-auth``
 ================
 
-File: ``apps/openedx/config/partials/auth.json``
+File: ``apps/openedx/config/partials/auth.yml``
 
 .. patch:: openedx-cms-common-settings
 

diff --git a/requirements/plugins.txt b/requirements/plugins.txt
@@ -1,12 +1,12 @@
-# change version ranges when upgrading from maple
-tutor-android>=13.0.0,<14.0.0
-tutor-discovery>=13.0.0,<14.0.0
-tutor-ecommerce>=13.0.0,<14.0.0
-tutor-forum>=13.0.0,<14.0.0
-tutor-license>=13.0.0,<14.0.0
-tutor-mfe>=13.0.0,<14.0.0
-tutor-minio>=13.0.0,<14.0.0
-tutor-notes>=13.0.0,<14.0.0
-tutor-richie>=13.0.0,<14.0.0
-tutor-webui>=13.0.0,<14.0.0
-tutor-xqueue>=13.0.0,<14.0.0
+# change version ranges when upgrading from nutmeg
+tutor-android>=14.0.0,<15.0.0
+tutor-discovery>=14.0.0,<15.0.0
+tutor-ecommerce>=14.0.0,<15.0.0
+tutor-forum>=14.0.0,<15.0.0
+tutor-license>=14.0.0,<15.0.0
+tutor-mfe>=14.0.0,<15.0.0
+tutor-minio>=14.0.0,<15.0.0
+tutor-notes>=14.0.0,<15.0.0
+tutor-richie>=14.0.0,<15.0.0
+tutor-webui>=14.0.0,<15.0.0
+tutor-xqueue>=14.0.0,<15.0.0
diff --git a/tests/commands/test_dev.py b/tests/commands/test_dev.py
@@ -8,8 +8,3 @@ def test_dev_help(self) -> None:
         result = self.invoke(["dev", "--help"])
         self.assertEqual(0, result.exit_code)
         self.assertIsNone(result.exception)
-
-    def test_dev_bindmount(self) -> None:
-        result = self.invoke(["dev", "bindmount", "--help"])
-        self.assertEqual(0, result.exit_code)
-        self.assertIsNone(result.exception)
diff --git a/tests/test_bindmounts.py b/tests/test_bindmounts.py
diff --git a/tests/test_env.py b/tests/test_env.py
@@ -258,6 +258,6 @@ def test_current_version_in_latest_env(self) -> None:
             ) as f:
                 f.write(__version__)
             self.assertEqual(__version__, env.current_version(root))
-            self.assertEqual("maple", env.get_env_release(root))
+            self.assertEqual("nutmeg", env.get_env_release(root))
             self.assertIsNone(env.should_upgrade_from_release(root))
             self.assertTrue(env.is_up_to_date(root))
diff --git a/tutor/__about__.py b/tutor/__about__.py
@@ -2,7 +2,7 @@
 
 # Increment this version number to trigger a new release. See
 # docs/tutor.html#versioning for information on the versioning scheme.
-__version__ = "13.3.1"
+__version__ = "14.0.0"
 
 # The version suffix will be appended to the actual version, separated by a
 # dash. Use this suffix to differentiate between the actual released version and

diff --git a/tutor/bindmounts.py b/tutor/bindmounts.py
diff --git a/tutor/commands/cli.py b/tutor/commands/cli.py
@@ -89,7 +89,6 @@ def get_command(
     cls=TutorCli,
     invoke_without_command=True,
     add_help_option=False,  # Context is incorrectly loaded when help option is automatically added
-    help="Tutor is the Docker-based Open edX distribution designed for peace of mind.",
 )
 @click.version_option(version=__version__)
 @click.option(
@@ -110,6 +109,9 @@ def get_command(
 )
 @click.pass_context
 def cli(context: click.Context, root: str, show_help: bool) -> None:
+    """
+    Tutor is the Docker-based Open edX distribution designed for peace of mind.
+    """
     if utils.is_root():
         fmt.echo_alert(
             "You are running Tutor as root. This is strongly not recommended. If you are doing this in order to access"
@@ -121,9 +123,15 @@ def cli(context: click.Context, root: str, show_help: bool) -> None:
         click.echo(context.get_help())
 
 
-@click.command(help="Print this help", name="help")
+@click.command(
+    name="help",
+    context_settings={"help_option_names": ["-h", "--help"]},
+)
 @click.pass_context
 def help_command(context: click.Context) -> None:
+    """
+    Print this help
+    """
     context.invoke(cli, show_help=True)