Reference the Docker container in the Zephyr Getting Started guide

[keith-zephyr]

The Zephyr Getting Started guide should point to the docker container information.

Describe the solution you'd like The docker container should be promoted as alternate method for getting started quickly.

As is the Zephyr docker container isn't easy to discover in the Zephyr documentation.

[stephanosio]

We do not want to encourage the use of a Docker container for local development because:

1. Docker tends to be slow and this results in an overall bad developer experience.
2. IDE integration is tricky. You can use something like devcontainer with VS Code, but you are still working inside a virtual environment and do not have access to all the host resources (e.g. host USB devices).
3. Docker does not natively support macOS and Windows. It can run as a VM, but that is completely decoupled from the host environment and also very slow.

For the above reasons, I do not think the Getting Started Guide is the right place for this kind of information. Maybe it would help to create a separate dedicated page for this.

cc @carlescufi @mbolivar-nordic

[OUNAVCON]

I support this being included into the documentation, because it improves the developer experience.

Being able to have a single development environment that is the same between all devs and CI is an efficiency increase. Both in the bring-up time for a developer and in preventing discrepancies between a developer system and the CI. Besides, the installation instructions are doing everything from the console anyways. The Docker approach is less steps and less error prone, especially for businesses where Windows is still the majority player. Debugging and hardware interactions are manageable through several other existing tools, you can use the launch.json in VS Code for example. It seems to work well for my team. Eclipse integration is available as well for use by other vendor tools, so you could debug there. Last I checked these vendors all used Eclipse as the basis for their IDE's ,TI, NXP, Infineon, SiLabs.

I would advise caution when focusing in on a single use cases. As an example, VS Code integration. Nordic's implementation of custom extensions into VS Code causes headaches when developing for non-Nordic based projects. These are great if you are an exclusive Nordic developer, but not so much if you are also developing Zephyr for other vendors.

My team uses Nordic's VS Code extensions for NRF BLE development and we use the docker container for all our other embedded development for Zephyr. It would be far easier and preferable to have one setup. Whether you are working on displays with LVGL, real time control systems, or when doing BLE development. Regardless of whether this on done on an ST, NXP, or Nordic silicon. Getting the docker image to run on Windows systems is much faster and less error prone than all the individual steps in the existing instructions. I also don't notice any significant increase in the build time when using the docker container versus a native build.

If the goal is to make Zephyr a pleasurable experience, then Docker is the better option based on my experience.

[keith-zephyr]

Because the docker is self-contained, some users may see this a lower barrier to entry. They can install docker, explore and build the code without "polluting" their existing development environment with the toolchains and other dependencies currently required by the getting started guide.

I'm not suggesting that docker replace the getting started guide - only that it gets promoted as another alternative.

[mbolivar-nordic]

We have a "beyond the getting started guide" that the folks at intel created a long time ago, but has languished for a long time when their fulltime documentation maintainer was sadly reassigned to another area of the company.

Perhaps we could resurrect efforts to make that file a nice place to be, and include this information there?

[carlescufi]

We have a "beyond the getting started guide" that the folks at intel created a long time ago, but has languished for a long time when their fulltime documentation maintainer was sadly reassigned to another area of the company.

Perhaps we could resurrect efforts to make that file a nice place to be, and include this information there?

I do agree that this is the better way to approach this, and the Docker info would belong there very nicely. +1 for @mbolivar-nordic 's proposal.

[gmarull]

I think that this content is actually beyond the beyond the getting started guide. A new section about IDEs/tools would be better IMO:

• Using Docker to develop with Zephyr (how to use it, integration with IDEs, etc.)
• Using VSCode (extensions, how to debug, etc)
• .... (name it)

There's nothing useful in the docs about setting up a development environment.

[erichotterbeefcurry]

@OUNAVCON Hi Ounvacon, in your reply you mentioned that debugging with building zephyr in docker is manageable. I am helping my team set up firmware development for the docker compose, and I've got building and flashing using west working, but haven't figured out a good way to debug. Can I ask you for some guidance on this?

[zephyrbot]

Hi @kartben, @carlescufi,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@keith-zephyr you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!