Python packaging 2

python, code

Despite me having published Definitive Guide to Python packaging back in 2016 (a fact I’ve forgotten myself as far back as 2019, because since then I’ve been using cx_Freeze for par2deep), a better resource for Python packaging came across my screen today: “Why not tell people to “simply” use pyenv, poetry or anaconda”.

There is great wisdom in this post, and I recognize much of it, having worked with tinkerers before. I used to tinker much more than I do now, because tinkering costs time that I don’t have, something that is basically equivalent to the author’s observation that most are far too busy checking out your new toy. Today even more than before I work in a ‘hostile’ environment, where the sysadmin is very much not your ally, and you’re going to work around limitations and therefore appreciate solutions that keep their list of requirements short. No brew for me, no conda, no installing anything outside of pip, and not even that (topic for another post). Failure modes cascade: indeed! For Arbor and my personal packages we decided to stick to solutions that require the least from the user, and I fought tooth and nail for wide Python-version support, neatly in line with the post, and worked hard to provide binary wheels. As any non-dev-dev knows: having to compile things is a recipe for quickly escalating problems.

I just wanted to add a few things: