Merge branch 'nightly' into olive

Makefile

@@ -40,7 +40,7 @@ test-unit: ## Run unit tests
 	python -m unittest discover tests
 
 test-types: ## Check type definitions
-	mypy --exclude=templates --ignore-missing-imports --strict ${SRC_DIRS}
+	mypy --exclude=templates --ignore-missing-imports --implicit-reexport --strict ${SRC_DIRS}
 
 test-pythonpackage: build-pythonpackage ## Test that package can be uploaded to pypi
 	twine check dist/tutor-$(shell make version).tar.gz

README.rst

@@ -55,16 +55,17 @@ Features
 * No technical skill required with the `zero-click Tutor AWS image <https://docs.tutor.overhang.io/install.html#zero-click-aws-installation>`__
 
 .. _readme_intro_end:
-
+..
+  TODO: replace image + alt with tutor local launch
 .. image:: ./docs/img/quickstart.gif
     :alt: Tutor local quickstart
     :target: https://terminalizer.com/view/91b0bfdd557
 
-Quickstart
+Launch
 ----------
 
 1. Install the `latest stable release <https://github.com/overhangio/tutor/releases>`_ of Tutor
-2. Run ``tutor local quickstart``
+2. Run ``tutor local launch``
 3. You're done!
 
 Documentation

changelog.d/20221124_172610_regis_nightly.md

@@ -0,0 +1,15 @@
+- [Improvement] Add the `-h` help option to all commands and subcommands. Previously, we could only use `--help`, which is quite long for lazy fingers. (by @regisb)
+- 💥[Feature] Add an extensible `local/dev/k8s do ...` command to trigger custom job commands. These commands are used to run a series of bash scripts in designated containers. Any plugin can add custom jobs thanks to the `CLI_DO_COMMANDS` filter. This causes the following breaking changes:
+    - The "init", "createuser", "settheme", "importdemocourse" commands were all migrated to this new interface. For instance,  `tutor local init` was replaced by `tutor local do init`.
+    - Plugin developers are encouraged to replace calls to the `COMMANDS_INIT` and `COMMANDS_PRE_INIT` filters by `CLI_DO_INIT_TASKS`.
+- [Feature] Implement hook filter priorities, which work like action priorities. (by @regisb)
+- 💥[Improvement] Remove the `local/dev bindmount` commands, which have been marked as deprecated for some time. The `--mount` option should be used instead.
+- 💥[Bugfix] Fix local installation requirements. Plugins that implemented the "openedx-dockerfile-post-python-requirements" patch and that needed access to the edx-platform repo will no longer work. Instead, these plugins should implement the "openedx-dockerfile-pre-assets" patch. This scenario should be very rare, though. (by @regisb)
+- 💥[Improvement] Rename the implementation of tutor <mode> quickstart to tutor <mode> launch. (by @Carlos-Muniz)
+- 💥[Improvement] Remove the implementation of tutor dev runserver. (by @Carlos-Muniz)
+- [Bugfix] Fix MongoDB replica set connection error resulting from edx-platform's pymongo (3.10.1 -> 3.12.3) upgrade ([edx-platform#30569](https://github.com/openedx/edx-platform/pull/30569)). (by @ormsbee)
+- [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] Remove edX references from bulk emails ([issue](https://github.com/openedx/build-test-release-wg/issues/100)).
+- [Bugfix] Update ``celery`` invocations for lms-worker and cms-worker to be compatible with Celery 5 CLI.
+- [Improvement] Point CMS at its config file using ``CMS_CFG`` environment variable instead of deprecated ``STUDIO_CFG``.
+- [Bugfix] Start MongoDB when running migrations, because a new data migration fails if MongoDB is not running

docs/configuration.rst

@@ -15,7 +15,7 @@ This section does not cover :ref:`plugin development <plugins>`. For simple chan
 Configuration
 -------------
 
-With Tutor, all Open edX deployment parameters are stored in a single ``config.yml`` file. This is the file that is generated when you run ``tutor local quickstart`` or ``tutor config save``. To view the content of this file, run::
+With Tutor, all Open edX deployment parameters are stored in a single ``config.yml`` file. This is the file that is generated when you run ``tutor local launch`` or ``tutor config save``. To view the content of this file, run::
 
     cat "$(tutor config printroot)/config.yml"
 
@@ -330,7 +330,7 @@ The following sections describe how to modify various aspects of the docker imag
 
     tutor local stop
 
-The custom image will be used the next time you run ``tutor local quickstart`` or ``tutor local start``. Do not attempt to run ``tutor local restart``! Restarting will not pick up the new image and will continue to use the old image.
+The custom image will be used the next time you run ``tutor local launch`` or ``tutor local start``. Do not attempt to run ``tutor local restart``! Restarting will not pick up the new image and will continue to use the old image.
 
 openedx Docker Image build arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -486,7 +486,7 @@ By default, Tutor runs the `overhangio/openedx <https://hub.docker.com/r/overhan
 
 (See the relevant :ref:`configuration parameters <docker_images>`.)
 
-The customised Docker image tag value will then be used by Tutor to run the platform, for instance when running ``tutor local quickstart``.
+The customised Docker image tag value will then be used by Tutor to run the platform, for instance when running ``tutor local launch``.
 
 
 Passing custom docker build options

docs/dev.rst

@@ -13,7 +13,7 @@ First, ensure you have already :ref:`installed Tutor <install>` (for development
 
 Then, launch the developer platform setup process::
 
-    tutor dev quickstart
+    tutor dev launch
 
 This will perform several tasks for you. It will:
 
@@ -51,14 +51,14 @@ To bring down your platform's containers, simply run::
 Starting the platform back up
 -----------------------------
 
-Once you have used ``quickstart`` once, you can start the platform in the future with the lighter-weight ``start`` command, which brings up containers but does not perform any initialization tasks::
+Once you have used ``launch`` once, you can start the platform in the future with the lighter-weight ``start`` command, which brings up containers but does not perform any initialization tasks::
 
   tutor dev start     # Run platform in the same terminal ("attached")
   tutor dev start -d  # Or, run platform the in the background ("detached")
 
-Nonetheless, ``quickstart`` is idempotent, so it is always safe to run it again in the future without risk to your data. In fact, you may find it useful to use this command as a one-stop-shop for pulling images, running migrations, initializing new plugins you have enabled, and/or executing any new initialization steps that may have been introduced since you set up Tutor::
+Nonetheless, ``launch`` is idempotent, so it is always safe to run it again in the future without risk to your data. In fact, you may find it useful to use this command as a one-stop-shop for pulling images, running migrations, initializing new plugins you have enabled, and/or executing any new initialization steps that may have been introduced since you set up Tutor::
 
-  tutor dev quickstart --pullimages
+  tutor dev launch --pullimages
 
 
 Running arbitrary commands
@@ -112,7 +112,7 @@ It may sometimes be convenient to mount container directories on the host, for i
 Bind-mount volumes with ``--mount``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``quickstart``, ``run``, ``init`` and ``start`` subcommands of ``tutor dev`` and ``tutor local`` support the ``-m/--mount`` option (see :option:`tutor dev start -m`) which can take two different forms. The first is explicit::
+The ``launch``, ``run``, ``init`` and ``start`` subcommands of ``tutor dev`` and ``tutor local`` support the ``-m/--mount`` option (see :option:`tutor dev start -m`) which can take two different forms. The first is explicit::
 
     tutor dev start --mount=lms:/path/to/edx-platform:/openedx/edx-platform lms
 
@@ -152,24 +152,6 @@ 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 ``breakpoint()`` 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.
-
 Manual bind-mount to any directory
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -283,6 +265,7 @@ Then, run unit tests with ``pytest`` commands::
     export EDXAPP_TEST_MONGO_HOST=mongodb
     pytest common
     pytest openedx
+    pytest xmodule
 
     # Run tests on LMS
     export DJANGO_SETTINGS_MODULE=lms.envs.tutor.test

docs/gettingstarted.rst

@@ -8,5 +8,5 @@ Getting started
 
    install
    intro
-   quickstart
+   quickstart 
    whatnext

docs/index.rst

@@ -1,7 +1,8 @@
 .. include:: ../README.rst
     :start-after: _readme_intro_start:
     :end-before: _readme_intro_end:
-
+..
+    TODO replace quickstart.gif + alt with 'launch'
 .. image:: ./img/quickstart.gif
     :alt: Tutor local quickstart
     :target: https://terminalizer.com/view/91b0bfdd557

docs/install.rst

@@ -91,20 +91,20 @@ To upgrade Open edX or benefit from the latest features and bug fixes, you shoul
 
     pip install --upgrade "tutor[full]"
 
-Then run the ``quickstart`` command again. Depending on your deployment target, run one of::
+Then run the ``launch`` command again. Depending on your deployment target, run one of::
 
-    tutor local quickstart # for local installations
-    tutor dev quickstart   # for local development installations
-    tutor k8s quickstart   # for Kubernetes installation
+    tutor local launch # for local installations
+    tutor dev launch   # for local development installations
+    tutor k8s launch   # for Kubernetes installation
 
 Upgrading with custom Docker images
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you run :ref:`customised <configuration_customisation>` Docker images, you need to rebuild them before running ``quickstart``::
+If you run :ref:`customised <configuration_customisation>` Docker images, you need to rebuild them before running ``launch``::
 
     tutor config save
     tutor images build all # specify here the images that you need to build
-    tutor local quickstart
+    tutor local launch
 
 Upgrading to a new Open edX release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -121,12 +121,12 @@ 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 Maple to Nutmeg 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 ``launch`` command (see above). The single difference is that if the ``launch`` 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 ``launch``. 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=maple
-    tutor local quickstart
+    tutor local launch
 
 .. _autocomplete:
 

docs/intro.rst

@@ -99,7 +99,7 @@ Because the Tutor environment is generated entirely from the values in ``config.
 
 You can now take advantage of the Tutor-powered CLI (item #3) to bootstrap your Open edX platform::
 
-    tutor local quickstart
+    tutor local launch
 
 Under the hood, Tutor simply runs ``docker-compose`` and ``docker`` commands to launch your platform. These commands are printed in the standard output, such that you are free to replicate the same behaviour by simply copying/pasting the same commands.
 
@@ -117,7 +117,7 @@ as well as command trees for each mode in which Tutor can run::
     tutor k8s ...    # Commands for managing a Kubernetes Open edX deployment.
     tutor dev ...    # Commands for hacking on Open edX in development mode.
 
-Within each mode, Tutor has subcommands for managing that type of Open edX instance. Many of them are common between modes, such as ``quickstart``, ``start``, ``stop``, ``exec``, and ``logs``. For example::
+Within each mode, Tutor has subcommands for managing that type of Open edX instance. Many of them are common between modes, such as ``launch``, ``start``, ``stop``, ``exec``, and ``logs``. For example::
 
     tutor local logs  # View logs of a local deployment.
     tutor k8s logs    # View logs of a Kubernetes-managed deployment.

docs/k8s.rst

@@ -85,19 +85,19 @@ The other benefit of ``kubectl apply`` is that it allows you to customise the Ku
 
 To learn more about "kustomizations", refer to the `official documentation <https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/>`__.
 
-Quickstart
+Launch
 ----------
 
 Launch the platform on Kubernetes in one command::
 
-    tutor k8s quickstart
+    tutor k8s launch
 
 All Kubernetes resources are associated with the "openedx" namespace. If you don't see anything in the Kubernetes dashboard, you are probably looking at the wrong namespace... 😉
 
 .. image:: img/k8s-dashboard.png
     :alt: Kubernetes dashboard ("openedx" namespace)
 
-The same ``tutor k8s quickstart`` command can be used to upgrade the cluster to the latest version.
+The same ``tutor k8s launch`` command can be used to upgrade the cluster to the latest version.
 
 Other commands
 --------------

docs/local.rst

@@ -18,7 +18,7 @@ In the following, environment and data files will be generated in a user-specifi
     tutor run ...
 
 .. note::
-    As of v10.0.0, a locally-running Open edX platform can no longer be accessed from http://localhost or http://studio.localhost. Instead, when running ``tutor local quickstart``, you must now decide whether you are running a platform that will be used in production. If not, the platform will be automatically be bound to http://local.overhang.io and http://studio.local.overhang.io, which are domain names that point to 127.0.0.1 (localhost). This change was made to facilitate internal communication between Docker containers.
+    As of v10.0.0, a locally-running Open edX platform can no longer be accessed from http://localhost or http://studio.localhost. Instead, when running ``tutor local launch``, you must now decide whether you are running a platform that will be used in production. If not, the platform will be automatically be bound to http://local.overhang.io and http://studio.local.overhang.io, which are domain names that point to 127.0.0.1 (localhost). This change was made to facilitate internal communication between Docker containers.
 
 Main commands
 -------------
@@ -32,9 +32,9 @@ All-in-one command
 
 A fully-functional platform can be configured and run in one command::
 
-    tutor local quickstart
+    tutor local launch
 
-But you may want to run commands one at a time: it's faster when you need to run only part of the local deployment process, and it helps you understand how your platform works. In the following, we decompose the ``quickstart`` command.
+But you may want to run commands one at a time: it's faster when you need to run only part of the local deployment process, and it helps you understand how your platform works. In the following, we decompose the ``launch`` command.
 
 Configuration
 ~~~~~~~~~~~~~
@@ -80,7 +80,7 @@ Service initialisation
 
 ::
 
-    tutor local init
+    tutor local do init
 
 This command should be run just once. It will initialise all applications in a running platform. In particular, this will create the required databases tables and apply database migrations for all applications.
 
@@ -120,7 +120,7 @@ Creating a new user with staff and admin rights
 
 You will most certainly need to create a user to administer the platform. Just run::
 
-    tutor local createuser --staff --superuser yourusername user@email.com
+    tutor local do createuser --staff --superuser yourusername user@email.com
 
 You will be asked to set the user password interactively.
 
@@ -131,7 +131,7 @@ Importing the demo course
 
 After a fresh installation, your platform will not have a single course. To import the `Open edX demo course <https://github.com/openedx/edx-demo-course>`_, run::
 
-    tutor local importdemocourse
+    tutor local do importdemocourse
 
 .. _settheme:
 
@@ -140,7 +140,7 @@ Setting a new theme
 
 The default Open edX theme is rather bland, so Tutor makes it easy to switch to a different theme::
 
-    tutor local settheme mytheme
+    tutor local do settheme mytheme
 
 Out of the box, only the default "open-edx" theme is available. We also developed `Indigo, a beautiful, customizable theme <https://github.com/overhangio/indigo>`__ which is easy to install with Tutor.
 

docs/plugins/intro.rst

@@ -11,7 +11,7 @@ Tutor comes with a plugin system that allows anyone to customise the deployment
     # 2) Enable the plugin
     tutor plugins enable myapp
     # 3) Reconfigure and restart the platform
-    tutor local quickstart
+    tutor local launch
 
 For simple changes, it may be extremely easy to create a Tutor plugin: even non-technical users may get started with our :ref:`plugin_development_tutorial` tutorial. We also provide a list of :ref:`simple example plugins <plugins_examples>`.
 

docs/plugins/v0/gettingstarted.rst

@@ -51,7 +51,7 @@ You should be able to view your changes in every LMS and CMS settings file::
 
 Now just restart your platform to start sending tracking events to Google Analytics::
 
-    tutor local quickstart
+    tutor local launch
 
 That's it! And it's very easy to share your plugins. Just upload them to your Github repo and share the url with other users. They will be able to install your plugin by running::