More flexible .devcontainer

[oscarlevin]

What do we think about building in more flexibility into the .devcontainer? I am right now waiting for a new user's repo to spin up a codespace. I am sure it is taking way longer than it needs to given what features the user needs and what is included regardless.

What I propose is that the template repo uses the most minimal .devcontainer. Then, any time that a user tries to build in the presence of latex-image, or tries to build a pdf, we update the .devcontainer to pull the better docker image and prompt them to reload if they are in a codespace. Similarly for the other components.

I don't understand docker enough to know if there is a slick way to pick and choose (or if it makes sense to add them outside the official docker image), but even using our three docker image sizes, I think this would be nice.

Thoughts?

[StevenClontz]

The killer feature I want: NO devcontainer, making documents reasonably editable using just GitHub.dev, but still provide a reasonable feedback loop for authors who are doing simple PreTeXt (e.g. no sageplot) (I almost said no latex-image but we could wire up tikzjax for that). Then we can bring in full PreTeXt at the build/deployment stage.

This can only happen if we have a Javascript implementation of enough of PreTeXt though. :-/

[oscarlevin]

Would you also like a pony?

[bjones1]

I agree this would be great, but accomplishing this in pure JS means we have no access to a filesystem containing images, source, etc. That's really hard to replace.

One step in this direction: a pre-built Codespace. We should consider paying for the necessary storage, then evaluating how useful this is.

[StevenClontz]

I don't believe that's quite accurate. VS Code cloud supports certain plug ins.

[StevenClontz]

I do agree that the quicker solution is a pre built codespace, and I think I can get it paid for if we need funds.

[oscarlevin]

I don't think the prebuilt codespace will help all that much. It would help if someone wants to quickly try out a codespace the first time (not sure if it persists if they start a new repo from our template), but once they have their own project started, anyone else building a codespace from their repo will have to do the full creation step (unless they have turned on prebuilds themselves).

[oscarlevin]

When I looked around 6 months ago, the answer seemed to be no. But it's worth keeping an eye out for.

[StevenClontz]

I think https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/setting-up-your-repository/facilitating-quick-creation-and-resumption-of-codespaces would have been the best bet, but it's mostly about making the Codespace features discoverable, not a way to somehow cache a pre-built codespace to speed up initial creation.

[bjones1]

The frustrating blocker here: we can't run our own VSCode-based server and still have the VSCode library of plugins. This is what we really want to do, but I can't see how. That would make authoring so much easier! The idea: a single server (or cluster of servers) would allow multiple users to log in and edit their Github-hosted documents. Since it's a server, there's no start-up time; even a small server could probably host a large number of users.

[StevenClontz]

We also take on some security risk once we run our own server, rather than having users use Microsoft's infrastructure.

[bjones1]

True! Given that Brad's already running a server, he's at least thought about some of those and kept his server running for years.