-
Notifications
You must be signed in to change notification settings - Fork 0
Tutor Adoption 4: Devstack Parity: Improve Dev Workflows #146
Comments
tutor dev
workflowstutor dev
workflows
tutor dev
workflowstutor dev
workflows
tutor dev
workflowstutor dev
workflows
I think it's great that you are attempting to resolve the underlying issues by attacking edx-platform directly. It's certainly the most difficult path forward, but also the one with the most potential. Let me know how if I can help. |
For me one of the recurring problems is that the edx-platform dependencies change all the time...
But later I need a custom edx-platform:
What I think we need is some way that we can automatically detect when there's a difference between the requirements specified in the current Or another way of phrasing that is, can things like #153 and openedx/edx-platform#31505 take us far enough that we run |
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Before this commit, setting up an edx-platform development environment took multiple steps: tutor dev launch tutor dev run --mount=/path/to/edx-platform lms bash >> pip install -e . >> npm clean-install >> openedx-assets build --env=dev This commit moves the steps under ``run`` into an init task, which is automatically run by ``launch``. Thus, setup is now one command: tutor dev launch --mount=edx-platform These extra init steps are only applicable when bind-mounting edx-platform (because bind-mounting the repository overrides some important artifacts that exist on the image, which must be re-generated). Thus, the new init tasks exists early if it detects that it is *not* operating on a bind-mounted repository. Finally, we try to simplify the Open edX development docs so that it is clearer how bind-mounting fits into the development process. These bind-mounts: * ../build/openedx/themes:/openedx/themes * ../build/openedx/requirements:/openedx/requirements existed in the dev lms and cms containers, but they did not exist in the lms-job and cms-job containers. This means that themes and requirements that were *built into the image* would exist in the job containers, but live updates to the themes and requirements would not apply. To resolve this, we set ``volumes:`` on the lms-job and cms-job services so that they match the volumes for the normal lms and cms services. Part of: openedx-unsupported/wg-developer-experience#146 Closes: openedx-unsupported/wg-developer-experience#152 This works around (but does not close) these related issues: * openedx-unsupported/wg-developer-experience#150 * https://github.com/openedx/wg-developer-experience/issues/151
Sorry Braden, I read your comment last month and totally forgot to respond. The workflow you bring up is a very common one and it's something I've been thinking about a lot! Something that makes this issue more challenging/interesting is that there are a bunch of containers all running edx-platform: lms, cms, their -worker variants, potentially their -job variants, and potentially any number of ephemeral Quickdev addresses this by using a shared, persisted volume for /openedx/venv across all containers. In that world, I bet it'd be possible to run Back to Tutor proper, though: without a shared /openedx/venv, updating requirements at runtime just does not seem viable. Instead, I think we'd need to make use of the Docker build, which is designed for the use case "when something changes, rebuild the affected parts (and only the affected parts)". Specifically, I can see two way of leveraging the Docker build:
Sorry, I know that's lot, but I would love to hear your thoughts when you have the chance @bradenmacdonald and @regisb . At the moment, requirements management for |
@kdmccormick Thanks! I'm not knowledgeable enough to predict how well your two ideas would work, but they're great ideas and I'd be very interested in seeing what happens if we try them out. |
tutor dev
workflowstutor dev
workflows
tutor dev
workflows
Option 2 seems quite inconvenient. In my experience, developers are not keen on moving their repos. But I might be wrong. I need to brainstorm this a little. FTR improving the dev workflow is also a top priority for me, and I agree that it's just a little too hard to hack on edx-platform as it is. Would it make our lives easier if we moved |
Agreed, it is worth considering. It makes me realize that bind-mounted tutor dev is currently in an awkward middle ground. One very important thing lives in the image:
whereas the rest of it lives in the bind-mount:
Perhaps we should pick a side. I am interesting in prototyping the first one. If you prototype the second one, we could compare results. Install/compile everything into the imageThis is the direction I've been heading. Firstly, I would do either (1) or (2) from my previous comment. Then, I would implement #150 and openedx/wg-devops#22, or some variation of those issues. Install/compile everything into the bind-mountWe would move /openedx/venv to /openedx/edx-platform/.venv. We could pip-install Python requirements again when initializating a bind-mounted platform. This would probably work well enough for Linux. Unfortunately, writing to bind-mounts on macOS is catastrophically slow, so asking those devs to run The current implementation of the |
FWIW I measured this just now; once the pip cache is populated, |
Let's try to consider this issue from the perspective of a macOS user, as it appears that it's the environment with the most constraints. What is the "right" way to run a containerized development environment in this context? Is there any hope at all, outside of running a native |
The major macOS constraint I've become aware of is don't write anything significant to bind-mounts. The two solutions that leads me to are:
FWIW, I do have a Mac to test on now. |
Yeah, using a virtual environment in the container is totally fine, as long as it's not bind-mounted. The problem is just that python doesn't have a simple/fast way to keep that venv in sync with the requirements files. Ideally there would be some readonly |
I am tempted to say that optimizing bind-mounts for macOS should not be our job, but then it seems that there are no practical solutions proposed upstream: docker/for-mac#3677 So we don't really have a choice, right? I am still not in favour of named volumes, so the only option left is to build as much as possible into the image, such that the bind-mounted volumes remain as small as possible. The good news is that I think we can achieve this without burdening the developers too much. I have a working proof of concept that works as follows:
So I think we can attempt to resolve this issue using this approach.
This is a really interesting idea. I understand we could achieve that goal with a quick-and-dirty script, but I wonder if there is any "official" way to run a combination of multiple virtualenv? |
Doesn't docker do this for us already though, if the base venv layer is established during the build, then it becomes readonly and any changes made it the container will be done in a copy-on-write overlay of the venv, as long as it's not bind mounted. |
We've made a lot of progress here, so I'm closing this, with two remaining follow-up issues: |
Background
#144 describes three options for improving
tutor dev
workflows around locally-changed code and requirements. This is one option.Notes
These tasks are based on this comment from the quickdev TEP:
The text was updated successfully, but these errors were encountered: