Skip to content

Blog

Creating a portable Python development environment

I set out on writing this post with a dream... A dream that whenever I was working in a shell environment, I would always have access to the aliases and commands that I'm used to, and that things would look exactly how I want them to. Whether that be at work, on my personal device or logging in to remote compute environments in the cloud.

Luckily I am not the first to have this dream, and through the guidance of Jake Wiesler I've been able to make this dream a reality and set up my own portable development environment.

Setting up a new Windows laptop for Python development

The Backstory

I've been doing a bit more development on my personal laptop lately and I was starting to brush up against the limits of my hardware. I have a Thinkpad X270, and although it comes with the renowned keyboard and a sturdy (not quite) bullet-proof chassis, I was starting to question the other parts of the spec... 8GB of RAM, an Intel i5-62000U processor and only 155GB of usable disk... I quickly ran out of space after setting up Windows Subsystem for Linux, a few versions of Python and some virtual environments.

Fair enough, I had a bit of bloat that I could slim down but I didn't want to have to make this a regular occurrence. Also, being a bit of a tab whore I was starting to experience a bit of slowness as I switched contexts between VS Code and my browser. Frankly, I could do with an upgrade. And although it had absolutely zero influence over this decision I was also experiencing a few ping issues when playing Age of Empires II: Definitive Edition online despite good ping and speeds on the internet tests... nope, no sway at all.

Chocolatey vs. Scoop vs Winget - which Windows package manager to use?

It didn't seem like that long ago that there wasn't much choice when it came to package managers on Windows, but as it finally matures a bit there are actually a few to choose from. Knowing the differences between them and which one to choose can be a little overwhelming at first, so in the process of trying to justify my own choices I thought I would write up this article to give a bit of background, explain the options available and some of the key differences between them.

Spell check git commit messages with this pre-commit hook

Us developers are often in a rush to get our commits up and nobody wants to meticulously check for spelling errors each time. However, it can be annoying when you check your commits on GitHub to see one.

commit spelling error
Argggh 😫

Sure, we can live with a spelling error here and there, especially if we squash commit messages when we merge. But if there's a simple way to fix them, then why not?

Auto-generating package API with mkdocstrings

Whenever I land on a new Python package docs these days, the docs tend to be built with mkdocs and the mkdocs-material theme, heralding a bit of a departure from the era of the Sphinx.

It's true, Sphinx still remains very popular and is endlessly extensible through its directives feature and its many plugins, but there is something about the beauty of mkdocs-material, its ease of deployment and its richness in features that makes it such a popular choice right now.