From Pycharm on Linux to VSCode on Windows

Switching development environments is always an adventure. As a longtime user of Manjaro Linux, I valued its cutting-edge updates. However, a recent update mishap left me contemplating a switch. I decided to venture into Windows, motivated by a desire to broaden my expertise across multiple operating systems. Typically, our development in idem takes place in a UNIX-like environment, with little to no Windows usage. As we are committed to open-source, it's crucial to ensure that Windows-based development is equally viable, even if it seems unorthodox for a distributed Python application like pop/idem.

From PyCharm to VSCode

My journey with PyCharm, marked by years of familiarity, faced roadblocks due to licensing issues, performance hiccups, and SSH interpreter complications. These challenges became more pronounced when alternating between home and work setups. Even IntelliJ Fleet, a potential alternative, fell short of my expectations, leading me to explore other options.

Why VSCode?

VSCode emerged as a beacon of stability and efficiency. Its seamless integration with various tools, lightweight nature, and free features, such as remote tunneling and a plethora of plugins including codegpt, made it an irresistible choice. Though I miss PyCharm's debugger and in-line code execution, VSCode's smarter debugging approach, particularly its adeptness at navigating through project-specific code, was a significant advantage.

Ubuntu and WSL

I began experimenting with Ubuntu on Windows Subsystem for Linux (WSL). WSL seemed like a bridge between Linux and Windows, but it introduced complexities in remote working scenarios. Given my hybrid work arrangement, the seamless transition between home and office was crucial, steering me away from WSL towards a purely Windows-based setup in VSCode.

Docker Desktop

Running nox and pre-commit directly on Windows led to various inconsistencies. Using system Python complicated things further, as pip-tools-compile would use windows paths instead of unix-style paths for dependencies. Hence, I opted to run these tools inside Docker containers.

One of the first steps in setting up my new environment was installing Docker Desktop. This proved crucial for running tools like pre-commit and nox, ensuring consistency with Linux.

Git Bash

For a familiar command-line experience, I installed Git Bash. Here’s my complete bashrc configuration, which includes Docker aliases for pre-commit and nox:

export MSYS_NO_PATHCONV=1
alias pre-commit='docker run -v ${PWD}:/src -v ~/.cache/pre-commit:/root/.cache/pre-commit -w /src -it --rm kiwicom/pre-commit pre-commit'
alias nox='docker run -v ${PWD}:/src -v ${PWD}/artifacts:/src/artifacts -w /src -it --rm thekevjames/nox nox'

I set Git Bash as the default terminal in VSCode. This, combined with the bashrc aliases, allowed me to maintain command consistency.

Python

I tried installing python from various sources on windows, including wingetui, chocolatey, and the microsoft app store. Each of those struggled with pathing and permissions. In the end, the best experience for me came from installing python straight from python.org. When i run "python -m virtualenv .venv" in the directory of the project I am working on, vscode picks it up right away and offers to use the new virtual environment for the project.

SSH Setup on Windows

Setting up SSH was crucial for secure connections. I ensured that my id_rsa, id_rsa.pub, and hosts file were correctly placed in Windows, which is typically under the %USERPROFILE%/.ssh directory.

VSCode Launch Configurations

Pycharm used run configurations that had a nice GUI with empty fields for all the possible values. In VSCode you have to create a launch.json file and manually edit it. For your reference, here is the launch configuration i use for development in idem:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Idem State",
            "type": "python",
            "request": "launch",
            "program": "/path/to/idem/run.py",
            "args": ["state", "/path/to/state.sls", "--reconciler=none", "--hard-fail", "--acct-file=/path/to/credentials.yaml"],
            "console": "integratedTerminal",
            "justMyCode": true
        },
        {
            "name": "Idem Exec",
            "type": "python",
            "request": "launch",
            "program": "/path/to/idem/run.py",
            "args": ["exec", "test.ping", "--acct-file=/path/to/credentials.yaml"],
            "console": "integratedTerminal",
            "justMyCode": true
        },
        {
            "name": "Idem Describe",
            "type": "python",
            "request": "launch",
            "program": "/path/to/idem/run.py",
            "args": ["describe", ".*", "--acct-file=/path/to/credentials.yaml"],
            "console": "integratedTerminal",
            "justMyCode": true
        },
        {
            "name": "debug test",
            "type": "python",
            "request": "attach",
            "purpose": ["debug-test"],
            "env": {"ACCT_FILE": "/path/to/creds.yaml"},
            "console": "integratedTerminal",
            "justMyCode": true
        }
    ]
}

Conclusion

This transition has been a learning curve, but it has reinforced the importance of being adaptable and platform-agnostic as a developer. While I still have a preference for Linux, working in Windows has opened up new ways of thinking and problem-solving, especially in a diverse team environment.