Slice up the development environment setup#437
Slice up the development environment setup#437mcrosson wants to merge 7 commits intozmkfirmware:mainfrom mcrosson:docs-setupcleanup
Conversation
mcrosson
commented
Nov 27, 2020
- Give a brief overview of docker+vscode vs native os
- Dedicated page for docker+vscode setup
- Dedicated page for native os setup
- Dedicated page for setting up zmk sources for development
|
Updated and pushed new rev based on feedback |
joelspadin
left a comment
There was a problem hiding this comment.
See also the unresolved comments from my earlier review, but this revision does seem easier to follow.
|
Updated and pushed per feedback. Will squash as last step before merge |
|
@mcrosson, I think this PR needs a health check? |
Health check? |
|
@mcrosson Would you mind rebasing again? I'd like to merge some of these old docs PRs. |
I can but I'd prefer the others be merged ahead of this as this update will likely cause a ton of other conflits with other doc updates. Would that work? |
|
Sure. Is there a way to keep track of what PR are blocking other PRs in github? |
I'm not sure offhand. There is a box towards that says "Linked issues" but i can't make changes If nothing else we can reference the others from this one and just keep tabs on things for a bit |
|
bump? anyone willing to review this if i fixup the conflicts we are getting more folks interested in windows + vscode + docker and i think this set of updates will be helpful for folks |
|
@mcrosson I'm happy to! |
idan
left a comment
There was a problem hiding this comment.
This looks fantastic! I did a scan for language and offered some suggested improvements, going to check this PR out and see how the docs look like built
| --- | ||
|
|
||
| :::danger | ||
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi. You must use the native environment if using an arm CPU. |
There was a problem hiding this comment.
Probably worth calling out apple silicon here as well
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi. You must use the native environment if using an arm CPU. | |
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an arm CPU. |
| ::: | ||
|
|
||
| :::note Windows Users | ||
| Please note the zmk builds can run slower with Docker on Windows if you don't use the WSL2 filesystem to store files. Build times can take 3-5 minutes on slower hardware without using the WSL2 filesystem. If you run into performance problems you can checkout the zmk sources inside a WSL2 environment and use `code .` inside the WSL2 environment to open the sources. This can make builds run as fast as 20s. |
There was a problem hiding this comment.
If the path of least resistance is installing Docker for Windows and letting that work the WSL2 magic behind the scenes, maybe we ought to recommend the happiest path upfront. Can also link to a section at the end that talks about the finer points of WSL and IO perf.
There was a problem hiding this comment.
I think we can leave this note but move it after the setup steps.
@innovaker was the one driving this add initially and I don't think it detracts from the rest of the information on the page.
|
|
||
| ## Environment Setup | ||
|
|
||
| There are two ways to setup the zmk development environment: Docker+VS Code (Docker in the rest of the documentation) and using the operating system directly (native in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. |
There was a problem hiding this comment.
| There are two ways to setup the zmk development environment: Docker+VS Code (Docker in the rest of the documentation) and using the operating system directly (native in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. | |
| There are two ways to setup the zmk development environment: Docker+VS Code (`Docker` in the rest of the documentation) and using the operating system directly (`native` in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. |
| Please see the [Docker](/docs/development/setup/docker-vscode) instructions or [native](/docs/development/setup/native) instructions to continue setup. | ||
|
|
||
| :::danger | ||
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi. You must use the native environment if using an arm CPU. |
There was a problem hiding this comment.
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi. You must use the native environment if using an arm CPU. | |
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an arm CPU. |
| sudo apt update | ||
| ``` | ||
|
|
||
| These commands should be run in a terminal such as Bash (Linux/macOS/Docker), PowerShell, or Command Prompt (Windows). |
There was a problem hiding this comment.
| These commands should be run in a terminal such as Bash (Linux/macOS/Docker), PowerShell, or Command Prompt (Windows). | |
| These commands should be run in a terminal such as Bash (Linux/MacOS/Docker), PowerShell, or Command Prompt (Windows). |
|  | ||
|
|
||
| Click `Reopen in Container` in order to reopen the VS Code with the running container. | ||
|
|
- Give a brief overview of docker+vscode vs native os - Dedicated page for docker+vscode setup - Dedicated page for native os setup - Dedicated page for setting up zmk sources for development
…ns. Expand some notes and caution boxes so some pitfalls and ways to improve performance are more clear to users
|
@idan TY for the suggestions, i've added them except for the last item with the screen shots. I'm not sure what you were suggesting in that last item and left it off. Would you be willing to provide some additional clarity? |
|
bump? i'd like to get this in before some of the other churn for the docs pops up... |
|
Apologies — yeah the screenshots were just referencing the two ways of getting at it, didn't mean them for inclusion. @mcrosson If you're okay with the content, I'd say |
i'm 100% good with content but i can't merge. That's gotta be @okke-formsma / @petejohanson / @innovaker / @Nicell |
Nicell
left a comment
There was a problem hiding this comment.
A few more suggestions, but I'd like to get this in soon. Doesn't need to be perfect. I think we need to consider if anywhere links to the old "Basic Setup" URL. We could probably set up a Netlify redirect for that.
|
|
||
| ## Environment Setup | ||
|
|
||
| There are two ways to setup the zmk development environment: Docker+VS Code (`Docker` in the rest of the documentation) and using the operating system directly (`native` in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. |
There was a problem hiding this comment.
| There are two ways to setup the zmk development environment: Docker+VS Code (`Docker` in the rest of the documentation) and using the operating system directly (`native` in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. | |
| There are two ways to setup the ZMK development environment: Docker+VS Code (`Docker` in the rest of the documentation) and using the operating system directly (`native` in the rest of the documentation). The Docker approach is a self-contained development environment while the native approach will setup your local operating system for development. The Docker approach is great for getting going quickly while the native approach is a bit faster but more difficult to setup initially. |
| :::danger | ||
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an arm CPU. |
There was a problem hiding this comment.
| :::danger | |
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an arm CPU. | |
| :::caution | |
| The Docker environment will **NOT** run on ARM CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an ARM CPU. |
| The Docker environment will **NOT** run on arm CPUs like the Raspberry Pi or Apple Silicon. You must use the native environment if using an arm CPU. | ||
| ::: | ||
|
|
||
| This setup leverages the same [image which is used by the GitHub action](https://github.com/zmkfirmware/zephyr-west-action) for local development. Beyond the benefits of [dev/prod parity](https://12factor.net/dev-prod-parity), this approach is also the easiest to set up. No toolchain or dependencies are necessary when using Docker; the container image you'll be using already has the toolchain installed and set up to use. |
There was a problem hiding this comment.
This action is deprecated now. Our actions now just use this docker image as the base image, so I think this first sentence isn't necessary or could be reworded to something like This setup leverages the same [Docker image used when building ZMK on GitHub](https://github.com/zmkfirmware/zmk-docker/). Also not quite sure how the dev/prod parity stuff fits into this discussion.
There was a problem hiding this comment.
It's there to be clear that the container used for local dev is the same as used by the github build system.
Basically a signal that if you want to be guaranteed what you do locally (dev) is the same as on the upstream build stuff (prod) you should be using the docker container for builds.
This should stand IMO for folks (like me) who want to use the same environment locally as is used by the build system to ensure there aren't surprises.
| 3. Install the [Remote - Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) | ||
|
|
||
| :::note Windows Users | ||
| Please note the zmk builds can run slower with Docker on Windows if you don't use the WSL2 filesystem to store files. Build times can take 3-5 minutes on slower hardware without using the WSL2 filesystem. If you run into performance problems you can checkout the zmk sources inside a WSL2 environment and use `code .` inside the WSL2 environment to open the sources. This can make builds run as fast as 20s. |
There was a problem hiding this comment.
| Please note the zmk builds can run slower with Docker on Windows if you don't use the WSL2 filesystem to store files. Build times can take 3-5 minutes on slower hardware without using the WSL2 filesystem. If you run into performance problems you can checkout the zmk sources inside a WSL2 environment and use `code .` inside the WSL2 environment to open the sources. This can make builds run as fast as 20s. | |
| Please note the ZMK builds run slower (up to 3-5 minutes on slower hardware) with Docker on Windows if you don't use the WSL2 filesystem to store files. If you run into performance problems you can checkout the ZMK sources inside a WSL2 environment and run `code .` to open the sources. This can make builds run at near-native speed. |
|
@Nicell incorporated your suggestions, i think this should be good to go? |
|
bump @petejohanson / @Nicell |
|
@mcrosson I'm good with these changes, but I still want to make sure we don't have any broken URLs. Could we add a redirect from |
I don't see a redirects file in the sources... @petejohanson probably has to be involved at this point |
You can add a |
|
Added the |
|
bump @petejohanson |
|
This pull request can now be closed as it was subsumed by #2272 which is now merged. |

