Blog

How to leverage an old dirty trick in your Bazel wrapper for great effect

As powerful as Bazel is, sometimes it’s not featureful enough. When using this build system, it’s common practice to wrap it in a launcher script—and in fact, this is natively supported by Bazelisk, Bazel’s native dispatcher that stands for the bazel binary in the user’s PATH. Bazelisk will first download the version of Bazel requested by the project, and then, if tools/bazel exists, invoke it instead of the downloaded binary. tools/bazel is what’s known as a Bazel wrapper and is the point of today’s article.

Well, not quite. The actual point of today’s article is to demonstrate a simple trick I learned from the GNU Autoconf and Automake days to implement full-blown conditionals in an ad-hoc template system. But because such trick is trivial once you see it, I have to present it in the context of a modern real-world scenario. So what I’m going to do is guide you through the creation of your very own Bazel wrapper to customize Bazel’s .bazelrc configuration file in ways that the native Bazel tool doesn’t support.

In a recent discussion at the orange site sparked by the Emacs 31 Is Around the Corner: The Changes I’m Already Daily Driving article, people were asking themselves “Is anyone still using Emacs?” and then providing their own perspective.

For me, the answer is a resounding yes… but the interesting part is that I’m not still using Emacs: I’m actually using Emacs again. And instead of burying my answer to the opening question in a long discussion thread, I thought I’d explain my journey with and without Emacs for the last… almost 30 years. At the end, I’ll unveil the specific feature that I feel gives me superpowers and that keeps me hooked.

This article is not about AI and it is not written with AI, but the work that I’m about to present was definitely motivated by AI. And because I generally like telling stories, I have to give you that background. Do with that whatever you want, but… it’d be a pity if you left just because the AI word showed up in the first paragraph! I think the technical explanation that follows is at the very least entertaining and also interesting independently of AI.

Back in December, I started toying with coding agents. One thing I tried, and for which I didn’t expect a lot of success, was to point an AI agent to the EndBASIC public documentation and ask it to write games like Space Invaders or Mario from scratch. And even though the results weren’t perfect and they didn’t work on the first try, they did work with a few tiny tweaks. Combining that with a bunch of hand-written AGENTS.md rules, I had an agent producing EndBASIC demos with ease.

This experiment was impressive because I did not expect an agent to be able to write EndBASIC code… and because it worked, it fueled my interest to pick EndBASIC’s own development back up. Three thoughts came to mind:

• Increase EndBASIC’s “self-documenting” aspects so that an AI agent can learn about its idiosyncrasies unsupervised.
• Speed up EndBASIC so that it can run more elaborate games.
• Extend EndBASIC with long-desired primitives like sprites and sound, to finally realize the vision behind the project.

These thoughts combined sparked the rewrite of EndBASIC’s core that I’ve been pursuing since January and which should see the light of day in the upcoming release. But before that happens, I want to talk to you about just one of the cool pieces behind the new core: namely, its approach to testing. I’ve stopped writing unit tests for the compiler and VM in Rust and I’ve switched to writing them in Markdown. And I believe this has turned out to be a pretty nice approach.

Six years have passed since I started building EndBASIC: a retro-looking BASIC interpreter that works on the web, on the desktop, and on embedded hardware—and that allows writing cross-platform apps that leverage graphics, a cloud file sharing system, and even access to local hardware via GPIO.

But as cool as this sounds, and as exciting as the journey has been, there is something that keeps bugging me about the future of the project: who wants to invest time building something new on an abandoned language? Even Visual Basic, a real platform that evolved over many years and gained “serious language features”, has fallen out of fashion and is, as far as I know, in “maintenance mode” by Microsoft.

So I’ve been thinking… “What if there was no BASIC in EndBASIC?” Or, in other words, how could I leverage the many pieces I’ve created underneath this project to build something that people actually want to use, be it for retro-style development or for other purposes?

Why agentic coding changes everything for the open-source craft and maintainership.

It has been two months since I’ve been using AI coding agents “for real”. In my previous article, I reflected on my experiment to vibe-code a full Emacs module from scratch. In there, I intentionally left one important question unanswered: what is the meaning and impact of agentic coding on the free software ecosystem we have all grown accustomed to?

Right now, I have many thoughts but no good answers, and the reason is that the more I use these tools, the more I doubt my long-held beliefs about open-source licensing. While I’ve found that agentic coding makes me more productive—provided I supervise the agents carefully, in some circumstances—it also distances me from the act of coding itself, stripping away the pride of craftsmanship and thus the desire to publish code as open source.

The bigger worry, however, is for the ecosystem as a whole. Let’s dive into what’s on my mind right now.

It has now been a month since I started playing with Claude Code “for real” and by now I’ve mostly switched to Codex CLI: it is much snappier—who would imagine that a “Rewrite in Rust” would make things tangibly faster—and the answers feel more to-the-point than Claude’s to me.

As part of this experiment, I decided to go all-in with the crazy idea of vibecoding a project without even looking at the code. The project I embarked on is an Emacs module to wrap a CLI ticket tracking tool designed to be used in conjunction with coding agents. Quite fitting for the journey, I’d say.

In this article, I’d like to present a bunch of reflections on this relatively-simple vibecoding journey. But first, let’s look at what the Emacs module does.

Or the more tired “One week with Claude Code”-type article.

It’s no secret that I’ve been grumpy about the new AI-based coding trend. I’ve been grumpy about the “push from above to use AI or else”. I’ve been grumpy about the eye-rolling hype I see on LinkedIn. I’ve been grumpy about being on the receiving end of vibe-coded PRs that over-engineer solutions to simple problems. I’ve been grumpy about the thought that we are about to see an amount of bloat like we have never imagined before.

But, at the same time, I’ve been using LLMs to review my articles, to perform deep research, to generate cover pictures, and before last week, I had even dipped my toes into AI-based coding agents to help me with boring, repetitive tasks. And you know what? I see their promise of increased productivity, yet the amounts of slop I’ve witnessed make me skeptical and I have had little experience with coding agents myself to judge their promised usefulness.

So… surprise! Last weekend I decided to start a Claude Code subscription and, after spending a week on it, I am uncomfortably excited to use it more. How has this happened? Let’s take a look at how I ended here, the kinds of mini-projects I worked on throughout this past week, and the (semi-expected) downsides I encountered.

A little over two years ago, I wrote an article titled SSH agent forwarding and tmux done right. In it, I described how SSH agent forwarding works—a feature that lets a remote machine use the credentials stored in your local ssh-agent instance—and how using a console multiplexer like tmux or screen often breaks it.

In that article, I presented the ssh-agent-switcher: a program I put together in a few hours to fix this problem. In short, ssh-agent-switcher exposes an agent socket at a stable location (/tmp/ssh-agent.${USER?} by default) and proxies all incoming credential requests to the transient socket that the sshd server creates on a connection basis.

In this article, I want to formalize this project by presenting its first actual release, 1.0.0, and explain what has changed to warrant this release number. I put effort into creating this formal release because ssh-agent-switcher has organically gained more interest than I imagined as it is solving a real problem that various people have.

Putting FreeBSD’s “power to serve” motto to the test.

On Thanksgiving morning, I woke up to one of my web services being unavailable. All HTTP requests failed with a “503 Service unavailable” error. I logged into the console, saw a simplistic “Runtime version: Error” message, and was not able to diagnose the problem.

I did not spend a lot of time trying to figure the issue out and I didn’t even want to contact the support black hole. Because… there was something else hidden behind an innocent little yellow warning at the top of the dashboard:

Migrate your app to Flex Consumption as Linux Consumption will reach EOL on September 30 2028 and will no longer be supported.

I had known for a few weeks now, while trying to set up a new app, that all of my Azure Functions apps were on death row. The free plan I was using was going to be decommissioned and the alternatives I tried didn’t seem to support custom handlers written in Rust. I still had three years to deal with this, but hitting a showstopper error pushed me to take action.

All of my web services are now hosted by the FreeBSD server in my garage with just a few tweaks to their codebase. This is their migration story.

It has been just over two years since I started Blog System/5, and that means it’s time for the now-usual(?) BazelCon 2025 trip report!

The conference, arranged by the Linux Foundation, took place in Atlanta, GA, USA over three days: one for tutorials and two for the main talks. An extra hackathon day, organized by Aspect Build, followed. Unfortunately, a canceled flight meant I missed the tutorials, but I attended the rest of the events. As usual, it was a super-fun time to connect with old acquaintances and an energizing event that left me with plenty of new topics to research.