Ensure that egg-info folder is created when edx-platform is mounted

[kdmccormick]

Background

This is a sub-task of #146.

What do we need to ensure? That the ./Open_edX.egg-info/ is generated in edx-platform and is up-to-date with any changes that have been made to ./setup.py. Essentially, in pseudocode, we want this:

if (not exists(Open_edX.egg-info)) or last_modified(Open_edX.egg-info) < last_modified(setup.py) then
        # Installs the current Python project.
        # This runs setup.py, which generates the egg-info folder we want.
        pip install -e .  
end

(For the sake of brevity, we're just going to call this theoretical script ensure-setup in the Tasks below.)

If edx-platform is not mounted, then ensure-setup is not necessary, because Open_edX.egg-info is already build and up-to-date in the openedx Docker image.

However, if edx-platform is mounted by a user, then Open_edX.egg-info is likely to be missing or outdated. If this happens, the user will face opaque errors about missing apps, stemming from the Django App Plugin or XBlock frameworks, both of which rely on a proper egg-info existing.

Tasks

Choose one of the following approaches:

A. Entrypoint script:

• Write an entrypoint script (we'll call it set-up-and-run). It should first do the ensure-setup thing. Then, it should run the arguments passed to it as a shell command.
  • For example: set-up-and-run ./manage.py lms runserver ... would create the egg-info if necessary, and then pass control to ./manage.py ....
• Add this script to the /openedx/bin folder of the openedx-dev image.
• Set the openedx-dev image's ENTRYPOINT to ['set-up-and-run'].
• Now, check that a mounted edx-platform can be run without needing to manually create the egg-info.
• Update the documentation to remove pip install .... from the mounted edx-platform setup steps.

B. Init task:

• Run ensure-setup in the LMS container as part of the do init job.
• Update the documentation to explain that launch (or do init) should be called when first mounting an edx-platform, but remove pip install .... from the mounted edx-platform setup steps.

C. Job + documentation: Write ensure-setup into a do-job, named edx-platform-setup. Then, in Tutor's Open edX dev setup docs, replace the stuff about pip install ... with:
tutor dev do --mount=edx-platform edx-platform-setup

D. Documentation alone: In Tutor's Open edX dev setup docs, replace the stuff about pip install ... with a simpler:
tutor dev run lms --mount=edx-platform pip install -e .

Notes

• On Option A-B vs. C-D: I think Options A or B are preferable if we could get them working and a palatable way, because it brings us closer to the dream of ✨ only one command to set up an Open edX development environment ✨.
• On Option C vs D: Option D seems preferable because it is simpler--there is no "job" obscuring what's going on. However, we do need to add additional setup steps to do edx-platform-setup for any reason, then I think Option C becomes superior.

[kdmccormick]

I am working on this now. I'll make PRs for both Options A and B so we can compare them side-by-side.

[kdmccormick]

@regisb , I've created a draft PRs for two different possible solutions to this issue:

• Option A: feat: use entrypoint to automatically pip-install mounted edx-platform  kdmccormick/tutor#24
• Option B: feat: add init task to pip-install mounted edx-platform kdmccormick/tutor#25

Take a look and let me know what you think.

I like Option A, because it means users don't need to re-run launch once they mount edx-platform for the first time. However, I've never used an ENTRYPOINT before, and I'm eager to hear why that may not be a wise decision for Tutor 😁

With either option, the end goal from #146 is to collapse the "setting up a development environment" instructions into one line, either:
a. tutor dev start --mount=edx-platform, or
b. tutor dev launch --mount=edx-platform, or

[regisb]

I understand the appeal of adding an entrypoint, but I would lean toward option B. Not so long ago, the openedx image that ships with Tutor did have an entrypoint. It was removed in this commit: overhangio/tutor@d5a790d

There are a few annoying issues with entrypoints, though none of them is major:

1. Entrypoint scripts are difficult to understand (to me). I have no idea what's the difference between "$@" and exec "$@", though I know that we should use the latter.
2. As a Docker user, I don't like it when a Docker image has an entrypoint because it's difficult to figure out which one it is. I have to look at the Dockerfile to understand what is going on.
3. Entrypoints are bypassed by docker exec. Thus, if important things need to happen in the entrypoint we can't run exec.
4. Entrypoints are a complexity magnet. Developers tend to add more and more stuff in them. This makes running docker run more and more complex.
5. It's tricky to override an entrypoint. Should entrypoint2.sh simply call entrypoint1.sh? I don't know (this is of course related to issue 1).

I understand that the entrypoint you are proposing is fairly simple, and thus some of these items do not apply here. Still, I would prefer if we managed to avoid adding that entrypoint back in.

[kdmccormick]

Those are all good points.

Point 3 isn't an immediate issue here since it's sufficient for pip install -e . to be executed on start, but as you point out, there's the risk of more things being stuffed into the entrypoint over time that could cause the exec quirk to become an issue.

Let me mull over this a bit more, but I think I'm on board with option B.

[kdmccormick]

I stuck with option B (from the comment above), and then went further and used the same init task for node_modules and for static assets: overhangio/tutor#813