I learned a few things about Go today. And got a good Rob Pike quote too:
a little copying is better than a little dependency - Rob Pike
I like Go, but I don’t use it really. I’ve thought about it many times, but I keep finding Python does my simple jobs just fine. What I like is the cross-platform story and the relative absence of the abstractionsim one finds in the C++ community: for most uses the most generic of fastest solution is not as important as writing code that’s easily understood.
The new things are the magic things at the bottom of the text, of which I only knew capitalisation for export. They are weird, but efficient, in a way, I guess.
It’s been a while since I last looked at Syncthing. At the time of writing, setup over a few devices was a bit of a hassle, having to manually copy over share-keys and then whitelist on every device every other device. What’s changed? Turns out: not much! I trialed Syncthing again some months ago and while you can now appoint a single devices as introducer, meaning that any peer will copy all peers, and all shares! Now that’s immediately a problem: I typically do not want to auto-share all shares. Removing the share won’t help, it’ll be readded within seconds. And do not configure a second introducer: you’ll never be able to remove a share ever again 😁 They’ll keep reintroducing it to each other.
Pity. They remain focused on rather fixed setups, and not sharing, as in, between family or friends.
Software engineers are not (and should not be) technicians is the title of the article, but I tried to give it a better summary. (Large) companies want predictability, predictable work is manual work, which means work doesn’t get automated, leading to inefficiency. It’s better to pay the one-time time-price for automation and then reap the benefits forever, than to produce steady progress because steady means not actually solving problems, just handling them.
I’m trying to figure out how to build Python packages that contains a binary component. There’s ton’s op options out there, scikit-build-core is what I last used. I wanted to repurpose hugo-python-distributions to get a few more commandline utilities up on PyPI, and here’s what I’ve learned:
There is no concept of cross-compilation in Python-land. See this discussion. Agriya very hansomely managed to implement an impressive build-matrix for the hugo-python package, but seeing as Go cross compiles natively, it’s a bit of a pity it’s necessary. cibuildwheel offers some functionality, but that is outside of the Python build, it just preconfigures a platform using QEMU for you. It’s fantastic that it works, but a rather time consuming and cycle-wasting way, given the option that Go already provides. I actually would like to re-use binaries from an existing build system and CI job, so just download them from somewhere, which makes setting up QEMU even more rediculous. If I could tell pip (wheel) for which platform tag it should build, I could tell also which file to fetch. But no, nothing let’s me do that.
I can write Python code that does it, but how do I do that when I just learned to delete setup.py and only use pyproject.toml? I can’t! Building requires code requires setup.py, it’s a simple as that. Well, I could use an external build system such as CMake and drive it using scikit-build-core, but that again is rather overkill than what’s a simple as copying a file based on the target platform.
So, setup.py it is. But I’ll write a new one from scratch for this project and not re-use the somewhat overengineered hugo-python-distributions chain. At least I’ve refreshed my memory on those wheel tags (PEP 425: Python version-Python ABI-platform), that the x and y in manylinux-x-y-arch refer to GLIB version (PEP 600) and that I can set the whole thing by hand if I know better, and when I’m going to just download a binary instead of building it, I should.
What would be nice if setuptools would let you specify what files (and not just deps) to include based on platform, and let you set the platform with a flag so I don’t actually have to be running it.
Serves me right for not simply checking in the binaries into the source tree 😁