Tutor Adoption 4: Devstack Parity: Dev Workflows

[kdmccormick]

Background

As described in the "Why" section of the quickdev plugin's documentation, the Tutor workflows involving installing and running locally-changed code/packages/requirements need improvement. As discussed in the quickdev TEP, we see three general paths forward:

1. Incorporate quickdev into Tutor.
   • Pros:
     • Makes the dev workflow improvement immediately available to all Tutor users.
     • No need to maintain quickdev as a plugin.
   • Cons:
     • Makes tutor dev much more stateful, counter to Tutor's design philosophy.
     • Creates a confusing difference of behavior between tutor dev and tutor [local|k8s].
2. Rewrite quickdev to be a proper long-term plugin that can work with any Tutor service. Maintain it as long as is needed.
   • Pros:
     • Dev workflow improvements are available to all Tutor users who install the plugin.
     • Avoids making vanilla tutor dev more stateful.
     • Keeps vanilla tutor dev behavior similar to tutor local.
   • Cons:
     • We would need to maintain two sets of dev docs: one for vanilla Tutor and another for Tutor+quickdev.
     • Plugin would need to maintained.
     • Installing quickdev is less seamless than it just being installed out-of-the-box.
3. Merge upstream fixes into edx-platform et al in order to alleviate the underlying problems.
   • Pros:
     • Dev workflow improvements are available to all Open edX devs, whether they use Tutor or not.
     • Nothing new to maintain: no additional Tutor core code nor additional Tutor plugin.
     • Avoids making vanilla tutor dev more stateful.
     • Keeps vanilla tutor dev behavior similar to tutor local.
   • Cons:
     • Seems to require the greatest development effort.
     • Less certain of a solution, since we don't have a proof-of-concept yet.

We could take a combination of paths (1+3 or 2+3). We could also start with a path and then reevaluate later (do 2 now, and consider 1 again later).

Note

This issue was previously broken into two separate issues:

• Improve workflow for mounted edx-platform development #73
• Improve workflow for platform plugin development #77

We've combined them into one issue because they share similar root causes and possible solutions.

Tasks

Evaluate the three paths forward. Prototype as necessary. Implement at least one of them.

#### Options
- [ ] https://github.com/openedx/wg-developer-experience/issues/148
- [ ] https://github.com/openedx/wg-developer-experience/issues/147
- [ ] https://github.com/openedx/wg-developer-experience/issues/146  

[kdmccormick]

I am currently working on Option 3: #146. We'll see how it goes.

[kdmccormick]

We have eliminated all options except:

• Tutor Adoption 4: Devstack Parity: Improve Dev Workflows #146

so I'm closing this issue in favor of that issue.