Why is the Docker container installation recommended for imports?

AI-generated summary

The discussion revolves around why Docker container installation is recommended for importing content into Discourse. Canapin references the official recommendation for using Docker for imports. pfaffman notes that importing on a production install avoids the need to upload backups from a home internet connection and allows for easy demonstration. gerhard explains that Docker is supported because development environments can vary widely, leading to potential issues with dependencies like Ruby versions or ImageMagick. pfaffman adds that even when developing import scripts, they use Docker for consistency, copying scripts into the discourse tree via a mount point with environment variables for database access.

What are the issues (or potential issues) using a development installation?

As for the import itself, is there any speed difference between a standard and a development installation?

I’ve started doing imports on a production install, mostly because that was I don’t have to upload the resulting backup from my home internet connection, and it’s very easy to show people the resulting import.

Mostly for the same reason we only support our Docker based setup when you install Discourse. We can’t really help you when we don’t know how the development environmental was set up. There’s simply too much that could go wrong. Different Ruby version, wrong version of ImageMagick, missing tools used for image processing,…

I can only speak for myself, but I run all migrations in a Docker container. I use my development environmental only for tweaking an existing script or developing a new one.

And I do that in docker deployment too. I have a script that copies the import script from a separate mount point into the discourse tree (and includes env for the database and such).