Meditations on Dependencies

I’ve got a long road ahead of me, and I’m getting a little overwhelmed. so it’s time for me to write it down!

Here is the list of tech I want to learn for beryl:

• please.build
• svelte
• wails
• Capacitor plugin development
• plugin architecture
• tweakable theming
• Language parsers
• automated testing

Any of these could be something that is an entire full-time job! And I want to learn them all in my spare time.

So it’s no wonder I’m spooked!

I think the core of what I’m trying to do isn’t really to build a cool todo list. What I’m really doing is trying to become a better developer.

I know how to use tools, and I know how to make stuff. But I’ve developed this in-curiosity about how my tools work. I expect to be able to follow a tutorial for ToolX, and immediately be able to accomplish what I want.

But that’s not really how programming works, is it? ToolX is going to need some system dependency I’ve never heard of. Or I get

ERROR: cannot combobulate assets: none

A day of frustrated googling later and it turns out ToolY v0.42 is not compatible with ToolX v10.14.2 so now I’m stuck.

I’m tired of this. I want to actually understand the tools I’m using. I don’t want to be stuck waiting for a ToolX maintainer to update their ToolY dependency, for a fix that hasn’t been made yet because the project is semi-abandoned.

I want to be the person submitting patches. I want to get familiar with my important dependencies, enough to be a maintainer! Not like a “making major changes” maintainer, but an “can build locally and fix bugs” maintainer.

I’ve spent the last few weeks learning please, and it’s a little frustrating. I’ve been trying to build my current beryl wails project with please, but I’m stuck because it seems like please doesn’t support the //go:embed all:path attribute.

This is, in my experience, pretty par for the course of using any tool. But instead of doing what I usually do, try a different tool, I’m going to dig my heels in. I suspect this is an easy fix, so I’m going to try to fix it!

I want to get out of this mindset that taking this approach is inefficient. Like yeah, when I’m doing this, I’m not making a todo list app. I’m fixing a subsystem in a build system that manages the build system that builds a todo list app that does not yet exist.

But I am learning. And by taking the time to deeply understand please, next year when something else inevitably breaks I’ll already have some experience, so I can have an easier time fixing it. And by doing this with all my systems, I hope that in the long run everything will get easier.

At the minimum I’ll be more experienced than I am now, and hopefully more confident!

I currently have some dread around dependencies! I don’t like the feeling that someone I don’t know can push code into my project which can prevent me from working on my planned task that day.

But at the same time, I’m one person. I can’t write all these libraries myself. I can’t be the one to notice and fix every security issue everywhere. My goals require me to engage with software development as it exists today, not how I’d like them to be. What I want to do is less useful to others if it doesn’t work on their iPhone 13, or their Chromebook, so I can’t exit the tech treadmill.

But I can become better at managing it. I’m learning how to manage dependencies. Instead of an unknown person pushing unknown code to me, I’ll be intentionally updating versions. Accepting the gift of new code from people that I am at least acquainted with.

To conclude, I’m going to try to reframe my attitude towards my side-projects in general. I’m not trying to sprint towards a goal. I’m learning how to contribute to open source, while learning new tools, while making something cool.