Simone Robutti

I haven't been writing videogames' reviews in many years now and I'm not changing my mind, but I want to talk about a videogame anyway: Mindustry. You can buy it for 5€ on Steam or just download a .jar file from Github and run it.


The game in itself is well thought, well designed and well executed. I don't want to go in detail about the merit of the game itself, but let's try to understand what it is about. It falls in the category of automation games, like for example Factorio, but it has much more prevalent Tower Defense elements. The player can dig up (infinite) resources, move them around and combine them in increasingly more complex chains through factories and different transporation methods. These resources can ultimately be fed to many different kinds of towers that will help you defend from waves of enemies, together with bots that can be created in dedicated factories. While these basic mechanics are just few and simple, Mindustry gives it a very horizontal width by allowing the player to build a big number of towers, fuel them in many different ways through a diverse set of production chains.

While the premise looks similar to Factorio (minus the ecologist message), the gaming experience is very different: Mindustry is faster, more multiplayer/PVP oriented and more open to personalized strategies. It is challenging without being (too) frustrating. In campaign mode, it introduces you to concepts gradually and leaves you enough time to experiment with them without being unnecessarily slow or repetitive. The sessions, both in single player and multiplayer, are shorter and more influenced by the specific layout of the map. Again, if you liked Factorio, you will like Mindustry but not because it's a “more of the same”.


What I want to talk about is something else. This game delivers a mature, cohesive, polished visual and gaming experience that, in my opinion, is rarely matched in an open-source game and the developer(s) should be commended for it. If you have been involved in an open source game development, you know how hard it is to give artistic and design coherence to the work of multiple developers. Mindustry, for what I know, took a different path: it is the product of mainly one developer, Anuken that open-sourced the game while retaining ownership of the development.

This is his main project and he took a rather bold strategy to promote it compared to most indie developers that follow more traditional monetization strategies. Nonetheless the game fits this model perfectly well: it's small enough, it has many orthogonal elements of gameplay, it has serendipity and small mods give a lot of added value. There are clear sinergies between its Open-Source nature and the design of the game.

Contrary to many other open source games that aim at reproducing commercial games (like 0 A.D. or FreeCiv) or others that target micro-niches of hardcore gamers (like Cataclysm: Dark Days Ahead), Mindustry has the ambition to create something new that caters to a wider audience. It delivers a real and proper game and not a toolbox to build your own gaming experience like too many niche games are doing. Not that this is bad, I've been a hardcore Dwarf Fortress fan for years and I loved games like Cataclysm or Aurora 4X, but it's now time for open source games to target a different crowd.

On top of this, the whole process of contribution and release is very well structured and trasparent. The documentation is ok and it's very easy to enter the development process. The game is developed in Java with LibGDX and on a technical level shouldn't be challenging to contribute to. I've used the library in the past without previous knowledge on gaming development and I managed to achieve very good results in a relatively short span of time.


The project is now just two years old and just landed on Steam, but as I said, it's already an extremely enjoyable experience as it is and has a very active community around it, with populated online servers. Is the game enough to start a new page of Open Source gaming? Probably not. Nonetheless is a small pearl that everybody in that world should consider as a blueprint to open up their projects. I hope that in the future the main developer will document better his subjective experience and give tools to other developers to emulate him.

When you first learn Python, somebody explains you that you can add the folder in which your source files sit to the PYTHONPATH environment variable and this code will then be importable from other locations. Too often this person forgets to say that this is a very bad idea in most scenarios. Some people discover this on the internet, some others just realize this by themselves. Too many people (especially non-programmers) just believe there's no alternative.

This blog post is for all of them, because even if you know that an alternative exists, it's not always easy to grasp. Python tooling is confusing because there are many software, built on top of each other, with a lot of overlaps with their concerns. It's hard to understand how they fit in the big picture.

For this reason I've decided to create a post that lists the most important tools, when and why they are used and what problem they solve. I will try to explain with simple words how you should approach each one of these tools. If a tool is here, it means that, as a Python programmer, you're supposed to at least know its existence. I will list only tools that can be applied to any project or workflow and that you should consider every time you start a new project. This doesn't mean you always have to use each one of them on every single project. Too much tooling can be easily be an overkill and become hard to maintain in some cases.



Setuptools is the standard way to create packages in Python. It's everywhere, it works and it fulfill its role.

For: building egg, zip or wheel files from source, define metadata for your project, share code in a structured and standardized way When: basically every time you want to write code that should run on somebody's else machine

Alternatives: Poetry, Flit


Virtualenv is a virtual environment manager. These isolated environments can be understood as self-contained python installations with independent packages installed. Using virtualenv means that you don't need to (and you shouldn't anyway) install packages using your default system's python installation.

For: keeping your dependencies separate, supporting multiple python versions in the same system, moving dependencies around easily When: you want to develop code, when you want to use a python version different than your default without going crazy

Alternatives: Docker or equivalent


Pip is the most common package management tool for Python. It allows you to take local or remote packages and install them in your virtual environment or system's Python.

For: installing and uninstalling packages, tracking versions of the packages you're using When: always

Alternatives: Poetry, Conda

Packaging and Distribution

For a more detailed overview, has a dedicated [page].(


distutils is a precursor of setuptools. The latter makes heavy use of features from distutils so it's not uncommon to have to interact with this tool. It's not something you should pick for your tool belt directly but you should be aware of where it fits in the big picture.


Pypi is the Python Package Index. It's a big repository of all your favourite Python Modules. Pip, for example, takes built packages from here.

For: publishing your code When: when you have a package that you want to make publicly available


Pypiserver is one implementation of the Package Index API used by Pypi. You can set up your own repository, for example for your whole company and publish packages there without releasing them to the public.

For: sharing code inside an organization When: this code shouldn't go public and you want to have control Alternatives: Warehouse (the one used by Pypi), djangopypi


Poetry is an alternative packaging system that replaces setuptools, pip and some of the tools built on top of them. It's an attempt to do a complete overhaul of how the Python packaging system works. So far it got some traction and lot of positive feedback but it's far from being the prevalent option.

For: handling and distributing packages, managing your dependencies, avoiding dependency resolution problems When: you have a fresh project and you're not afraid to use a relatively niche tool Alternatives: Pipenv


Pipenv, like Poetry, is a tool to structure your Python project dependencies and configurations in a more sane way. Through a Pipfile, it manages the dependencies for your project and ensure consistency and ease of use.

For: handling and distributing packages, managing your dependencies When: you want something like Poetry that will raise less questions Alternatives: Poetry



Sphinx is a tool to build documentation. It was born originally to handle Python's documentation but has now graduated to a general purpose documentation tool. It remains the most common option for Python Projects.

For: producing PDF or HTML documents from reStructuredText sources When: you want to have external documentation for your project, your APIs and your code Alternatives: Docutils, Doxygen


autodoc is a fundamental extension to Sphinx that allows you to generate restructuredText files from Python source code with entries for each class, function, module and so on.

For: documenting your code or APIs When: probably every time you're using Sphinx for a project Alternatives: autosummary



py.test is, in my opinion, the best test suite available in Python. It has plenty of features even though not all of them are presented properly so it takes some time to discover all the many possibilities supported by this software

For: testing your code When: always, you lazy ass Alternatives: unittest, nose


Hypothesis is a tool for property-based testing. Briefly said, it generates random test scenarios according to your specifications until it finds a case that makes your test fails. Take some time to learn the principles behind before starting to use this tool.

For: testing code, especially data processing When: you need to test non-trivial logic with a wide input space (numbers, strings, structured data)


tox is at its core a virtualenv manager for testing. It means that you can configure it to run your tests in a series of clean, customizable virtual environments to ensure that your code will be able to work under different conditions. All of this without any manual work required.

For: code that needs to run in different conditions and environments. Also useful for CI. When: your code needs to support different Python versions, run in different environments and in different operative systems Alternatives: bash scrips, CI pipelines



pyenv is a python version manager. It aims to simplify the local workflow of developers when handling multiple versions.

For: running different projects with different python versions When: you need to run with global python versions and you have many Alternatives: manual management, virtualenv, Poetry, Pipenv


PyScaffold is a tool to initialize your project structure in a standardized way and to provide some of the tools we listed before without need to configure them manually. It's heavily customizable.

For: bootstrapping projects, have multiple projects with uniform tooling and structure When: always (as long as you know the tool, don't use it the first time if you're in a rush) Alternatives: python-project-template, Cookiecutter


flake8 is one of the most used linters for Python. It runs different scripts to verify the compliance of your code with Python's style guide requirements (PEP-8).

For: verifying and guaranteeing good code style in your project When every time your project needs to be read by somebody, including yourself Alternatives: pylint


Black is an automatic code formatter. It means that instead of just checking your code for compliance, Black will actually modify it to make it compliant.

For: formatting your code automatically When: you have no problem giving up manual control over your code look Alternatives: autopep8, yapf,

edit: I'm compelled to specify that this post is not to be taken seriously, it's satire if you want and most of the statements are ironical in nature. Don't take it literally.

Inspired by this post I've decided to write a post about the worst programming Language Names.

Programmers are often notoriously bad at naming things and sometimes managers help them too. This produced many specimens of badly named languages that made it harder to use and discuss them. Here are the ones I dislike the most.


How is it pronounced? Sequel or S.Q.L? And then a Sequel to what? It's too old, all those remember are probably dead or working as clerks now. Don't get me started with all the problems it creates with PostsgreSQL. Is it Postgres or Postgre?


Go. Go where? And why? How is a novice supposed to Google it? Should we just call it Golang? It sounds too Oriental.


Can you at least make an effort and come up with a real name? It's not a name, it's a letter. If I call a variable “c” everybody gets mad, but apparently it's fine to call a language “C”.


Scala is a shortening of Scalable. Fair enough, that's clear. But in Italian it also means stairs. Therefore the logo is the staircase of an EPFL building, where Scala has been developed. The problem is that stairs are not really scalable. Also Teatro alla Scala is a very famous Opera House in Milan and it happened at least once that a lady came to the Milan Scala Meetup with a little kid, expecting it to be about Opera or something like that. They sat through the whole talk. It was something about monads. It's always about monads. Well, they should have picked a less ambiguous name.


I've recently entered the community and started to learn the language. I still sometimes forget to write “Ponylang” and Google keeps reminding me that the target audience of My Little Pony is single guys with hygiene problems. I just want to share mutable state between my actors without facing the horrors produced by modern society. Sean, I'm disappointed.

Enter your email to subscribe to updates.