Periodically I find myself switching back and forth between different and editors and workflows to try and be the most productive, depending on what kind of work I’m doing. Usually when in python, that involves some variation of writing python libraries / modules and exploratory development in jupyter notebooks of some kind. The goal is to try and minimise the friction encountered working between different sources. These are the combinations I’ve tried over the last couple of years:

To SSH into instances on AWS (or generally do anything where the internet needs to talk to the instance) one needs to set up inbound rules within a security group attached to an instance. For SSH, generally I only want to whitelist a single IP address - my own. Today I learnt that AWS can automatically set your IP: By selecting “My IP” from the “Source” dropdown. At first I was a bit worried this was a little bit too clever and might start updating records whenever I log into AWS - but fortunately not - it’s just to populate the IP on this screen.

Recently, the Scientific Python development guide)[https://learn.scientific-python.org/development/] was (announced and released, serving as a consolidation of existing developer guides outlining software development best practices in the scientific python ecosystem. It’s grown out of a collection of materials for Scikit HEP which I’d first encountered years ago, looking for python support for ragged arrays and noted the very useful documentation pages. It’s very nice to see a consensus backed series of guidelines and first principles in a consolidated location, as python packaging is esoteric at times, and has a long legacy of deprecated ways of doing things (which often are unfortunately still in regular use).

I’ve previously written a post about how to set up a developer environment for GeoPandas which is based upon the latest commit of pandas on github. With pandas 2.0 (or perhaps a minor patch after), pandas switched to using a meson based build backend - and this updates the instructions accordingly. This post draws from my previous one, plus elements of this post, with some of my own fixes added.

Although python has a functional story around packaging, there are plenty of footguns for people who only occasionally dabble with package management. This situation is fairly common in my line of work, when a project is started, the project team get set up with working developer environments, and then happily forget about packaging problems for the next x months until the next project starts. So this is a quick reference I hope to point people to the next time I get “my python environment isn’t working / I can’t install package x questions”.