Forem: Y.Matsuda

Introducing lazypkg – A Cross-Package Manager Tool for Effortless Updates

Y.Matsuda — Sun, 23 Mar 2025 01:49:50 +0000

How do you manage packages installed via different package managers?
In my case, I use macOS for work and Linux for personal development, so I manage most of my tools and configurations (like dotfiles) using Nix flakes + Home Manager.

That said, for tools I just want to quickly try out or tools specific to a single project, I often end up installing them via brew, npm install -g, or apt.

The problem is—once you’re juggling multiple package managers, it becomes hard to keep track of which packages are outdated. Plus, the command-line options vary across tools (was it update or upgrade ...?).

So I Built a TUI App Called `lazypkg`

To solve this, I built lazypkg—a terminal-based tool that lets you view and update packages across multiple package managers.

https://github.com/ymtdzzz/lazypkg

We'll dive into usage later, but here’s a quick overview of what it can do:

List upgradable packages:
- Package name
- Current version
- Latest version
Update individual packages
Update all packages at once

As of March 22, 2025, the following package managers are supported (with a modular design to allow easy additions):

apt
gem
homebrew
npm
docker

Docker support is disabled by default to avoid hitting Docker Hub API rate limits.

Getting Started

Installation

You can install lazypkg via Homebrew or go install.

# Homebrew
brew install ymtdzzz/tap/lazypkg

# go install
go install github.com/ymtdzzz/lazypkg@latest

Check if it’s installed:

lazypkg -v
# -> lazypkg version 0.0.7

Launch & View Upgradable Packages

Running lazypkg automatically detects supported package managers, populates the sidebar, and fetches package updates.

If a package manager (like apt) requires root, a password prompt will appear.

I updated everything before writing this post, so screenshots below use demo data.

Initially, focus is on the sidebar:

Here are the basic keybindings:

↑↓ or j/k: Move focus up/down in the sidebar
Enter or → or l: Switch focus to the package list pane
Space: Add manager to bulk update targets
r: Refresh updates for the selected manager
u:
- With no bulk target: Update all packages under current manager
- With bulk target(s): Update all selected managers’ packages

These operations mostly work the same in the package list pane as well.

Use Cases

Updating a Specific Package

Say you want to update only terraform under homebrew.
Focus on homebrew in the sidebar, then press Enter or → or l to move to the package list.

Focus on terraform, press u, and a confirmation dialog appears.

Press Enter to execute. Logs appear in real-time at the bottom (ctrl+j / ctrl+k to scroll).

The demo just fakes logs—actual command would be brew upgrade terraform.

Once done, the package list refreshes and removes terraform from the upgrade list.

Updating Multiple Packages

You can select multiple packages with Space. Let’s try selecting ffmpeg, terraform, and wget.

Then press u, confirm, and they’ll all be updated in one go.

Update All Packages under a Package Manager

To update all packages managed by, say, apt:
Return focus to the sidebar with Backspace, ←, or h, focus on apt, and press u. That’s it.

Alternatively, pressing a in the package list achieves the same thing.

That’s the gist of using lazypkg. Next up, the motivation and implementation details.

Why Build This When Tools Like `topgrade` Exist?

There are already some tools which have the same concept like topgrade

https://github.com/topgrade-rs/topgrade

It’s a fantastic tool and I used it for a while myself. But topgrade doesn’t show you which packages can be updated or what the new versions will be before updating—it just updates everything.

While that simplicity is great, I wanted a tool that takes a slightly different approach.

When it comes to globally installed packages, despite the interface differences, our needs are often:

View installed packages
Check for updates
Update selected packages

And frankly, I don’t care which manager is handling it—as long as something like lazypkg abstracts over the differences, the UX becomes so much smoother.

I decided to skip the “list installed packages” feature, since just knowing what’s outdated is usually enough.

Implementation Notes

Still a bit rough, but I want to highlight some design choices. The tool is written in Go, which I’m most comfortable with.

Chose `bubbletea` for TUI Framework

I’ve built other TUI tools, like otel-tui, which uses tview.

https://github.com/rivo/tview

otel-tui needed a custom frame graph renderer, and tview was perfect for that.
But this time, I wanted an Elm-style architecture with clear state transitions, so I chose bubbletea.

It wasn’t a heavily researched choice (it’s personal dev, after all), but I figured the event-driven model would better suit async tasks like package updates.

In bubbletea, you modify state (Model) only via messages. For example, updating a package involves two messages:

// https://github.com/ymtdzzz/lazypkg/blob/85b8a4e01fb5c5a75797f530e8893e871759104b/components/messages.go#L27C1-L36C2
type updatePackagesStartMsg struct {
    name string
    pkgs []string
}

type updatePackagesFinishMsg struct {
    name string
    pkgs []string
    err  error
}

On update finish, I hide the loading spinner and re-fetch updates:

// https://github.com/ymtdzzz/lazypkg/blob/85b8a4e01fb5c5a75797f530e8893e871759104b/components/packages.go#L149-L157
    case updatePackagesFinishMsg:
        if msg.name == m.name {
            for _, pkg := range msg.pkgs {
                if i, ok := m.pkgToIdx[pkg]; ok {
                    m.loading[i] = false
                }
            }
            cmds = append(cmds, m.getPackagesCmd())
        }

Compared to tview, which offers a lot of flexibility and lets you structure state management your own way, bubbletea provides more built-in guidance with its Elm-style architecture—making it easier to follow a clear path, especially in personal projects.

Still, as the app grows, centralizing all messages in one file won’t scale. That’s a future refactor.

Extensible Design

Right now, only a few package managers are supported, but I’ve made it easy to extend.

Each package manager is implemented as an executor that fulfills this interface:

// https://github.com/ymtdzzz/lazypkg/blob/85b8a4e01fb5c5a75797f530e8893e871759104b/executors/executor.go#L18-L39
// Executor defines the interface for package management operations
type Executor interface {
    // GetPackages retrieves a list of available package updates.
    // The password parameter is required for package managers that need elevated privileges.
    GetPackages(password string) ([]*PackageInfo, error)

    // Update performs an update operation on a single package.
    // If dryRun is true, it will only simulate the update without making actual changes.
    // The password parameter is required for package managers that need elevated privileges.
    Update(pkg, password string, dryRun bool) error

    // BulkUpdate performs update operations on multiple packages simultaneously.
    // If dryRun is true, it will only simulate the updates without making actual changes.
    // The password parameter is required for package managers that need elevated privileges.
    BulkUpdate(pkgs []string, password string, dryRun bool) error

    // Valid checks if the package manager is available and usable on the current system.
    Valid() bool

    // Close performs any necessary cleanup operations when the executor is no longer needed.
    Close()
}

If you're curious, here’s the Homebrew executor implementation, where brew outdated --verbose output is parsed via regex (yep, kind of hacky).

As for the password argument—I've built in a prompt that’s triggered automatically when elevated privileges are needed. The flow looks like this:

Attempt command with empty password (expecting failure)
Detect error output, show password dialog
On user input, re-run command with provided password

Passwords aren’t stored in structs or memory unnecessarily—they only exist within specific function scopes.

Closing

lazypkg is a pretty simple tool, but I use it every day and find it genuinely useful.
There are tons of features I’d like to add—UI polish, support for more managers—but it’s already functional and I plan to keep maintaining it.

If you face similar pain points with managing packages, I hope lazypkg helps.

Feedback is more than welcome!

otel-tui: A TUI Tool for Viewing OpenTelemetry Traces

Y.Matsuda — Sat, 29 Jun 2024 06:08:17 +0000

Introduction

The OpenTelemetry ecosystem has grown significantly busier compared to a while ago. I've been contributing and writing blog posts about it for about two years now, and I'm hoping to participate in some synchronous events in the future.

Now, when it comes to instrumenting applications or writing libraries for instrumentation, how do you usually verify the local operation?

From my experience, many people run Jaeger or Grafana locally to check signals. Today, I’d like to introduce a new method: my custom tool "otel-tui," which allows you to view OpenTelemetry in your terminal!

https://github.com/ymtdzzz/otel-tui

Motivation

The Need for a "Just Right" Tool for Local Development

Based on my experience, here are some use cases for verifying signals locally:

Ensuring traces are linked as intended
- For example, verifying implementation at the level of context
Checking that attributes are set as expected
- Attributes specified by the vendor may not display correctly if missing
- Custom attributes may be specified

Currently, there are several ways to verify signals (mainly traces) locally:

Run Jaeger (all-in-one with UI) or Grafana Tempo containers locally to send and view signals
Use an exporter to output to standard output or files

However, these methods have limitations:

Running Jaeger or Grafana Tempo containers locally is resource-intensive
Production-grade features are often too much for local use (e.g., service maps)
It’s challenging to view outputs in real-time

Using an exporter to output to standard output or files also has limitations:

Low readability (e.g., grepping for Trace ID or parent Span ID to check trace linkage)

Given these challenges, I wanted a tool that could offer the best of both worlds—one that wasn’t too heavy for local use and provided readable outputs.

There're Similar Tools but...

There’s also "otel-desktop-viewer," which focuses on viewing OpenTelemetry signals locally and is very user-friendly.

However, with a significant volume of data over a long period, it can become sluggish in terms of query and screen rendering (depending on machine specs). This inspired me to create my own tool that could view data in real-time without opening a browser and maintain stable performance.

Features

Here's what the screen looks like:

Key features include:

Traces
- List view of service spans and search by service name
- Detailed attribute information
- Trace graph display (waterfall diagram)
Logs
- List view and search
- Jump from logs to corresponding traces
Performance
- Lightweight and real-time screen updates (asynchronous signal reception and rendering)
- No memory leaks even with a steady flow of data over a long period (data rotation)

TODOs

There are still many features missing:

Flexible settings
- Screen update frequency
- Buffer size
Metric collection and display
Stability
- Occasional crashes after prolonged use
Consistent keybindings
UI improvements
- Navigation (e.g., back and forth between traces and log details)
- Text wrapping, waterfall diagram
- Debug logs

How to Use

To demonstrate usage, I’ll use signals from the "opentelemetry-demo."

Installing otel-tui

You can install it via Homebrew:



$ brew install ymtdzzz/tap/otel-tui

If Homebrew isn’t available, download the binary from the release page or build from source.

Verify installation with:



$ otel-tui -v

otel-tui version 0.1.2

$ otel-tui -h

Usage:

  otel-tui [flags]

Flags:

      --grpc int      The port number on which we listen for OTLP grpc payloads (default 4317)

  -h, --help          help for otel-tui

      --host string   The host where we expose all endpoints (OTLP receivers and browser) (default "0.0.0.0")

      --http int      The port number on which we listen for OTLP http payloads (default 4318)

  -v, --version       version for otel-tui

Changing the Target of the Instrumented Application

Clone the "opentelemetry-demo" repository and configure it.

Modify Collector Target

The opentelemetry-demo consists of multiple microservices, all signals are aggregated in the OpenTelemetry Collector. Modify the collector's exporter target to point to otel-tui.



# src/otelcollector/otelcol-config-extras.yml

exporters:

  otlp:

    endpoint: host.docker.internal:4317

service:

  pipelines:

    traces:

      exporters: [spanmetrics, otlp]

    logs:

      exporters: [otlp]

Allow Container to Host Port Communication (if not using Docker Desktop)

Set up host.docker.internal to be resolvable from within the container.



# docker-compose.minimal.yml

# OpenTelemetry Collector

otelcol:

  image: ${COLLECTOR_CONTRIB_IMAGE}

  container_name: otel-col

  # ...

  extra_hosts:

    - "host.docker.internal:host-gateway"

Starting otel-tui and the Instrumented Application

Start them in separate tabs.



  
  
  From any directory where otel-tui is in the PATH


$ otel-tui



  
  
  From the root of the opentelemetry-demo repository


$ make start-minimal

Exploring Data

After a short while, signals should start flowing into otel-tui.

You can switch between traces and logs using the Tab key. Navigate through panes using keys listed in the titles (e.g., Details(d)).

To filter the spans, use the search box (/ key) and search for something like "product."

Spans related to services with the prefix "product" are filtered. Details of the currently focused span are displayed in the Details pane. You can collapse the tree in the Details pane by pressing Enter.

Select a span in the Traces pane by pressing Enter to view the trace details.

Navigate the Trace Timeline using arrow keys. Details of the focused span appear in the Details pane. Related logs appear in the Logs pane.

Press Esc to return to the trace list, and Tab to switch to the logs view.

Search for a term and inspect the details. If a log has a linked trace (indicated by a link emoji 🔗), press Enter to jump to the trace details.

This tool helps verify if the instrumented application sends the intended information and if it’s correctly linked.

Conclusion

While there are still many rough edges and missing features, I find it quite user-friendly and enjoyable to use.

I’d appreciate any feedback via https://github.com/ymtdzzz/otel-tui/issues or https://twitter.com/ymtdzzz!

[OpenTelemetry] Observability of Async Processes with Custom Propagator

Y.Matsuda — Thu, 22 Dec 2022 23:57:21 +0000

It’s the 23rd day of Makuake Advent Calendar 2022 .

As we know OpenTelemetry is an observability framework to generate and export telemetry data. As more companies adopt microservices and SLI/SLOs, we need it to answer new, never-before-seen (and complex) questions.

In that context, observability of systems that communicate using asynchronous messaging is as important as systems communicates using synchronous messagin like HTTP or gRPC.

How about a notification system as an example:

How long does it take for the end-user to receive the notification after the notification event is fired?
What’s the error rate access the notification lifecycle?

To answer those questions, we may need expensive and unique structures.

Instead, in this article, I’ll demonstrate an easy way to do that with OpenTelemetry.

Example Case

All source code is here:

https://github.com/ymtdzzz/batch-tracing-sample

Processing flow:

Enqueue the notification content as a message into a queue (Rabbit MQ) in batch
A worker (consumer) asynchronously receives the message and send a request to the notification server (/email or /push)
In the notification server, it responses 200 or 500

It’s assumed that the instrumentation of each component has been completed, and the HTTP communication has also been instrumented by net/http auto instrumentation library.

Problem

In the current state, batch processing and subsequent processing (worker) cannot be traced.

Moreover, there doesn’t seem to be an instrumentation library for RabbitMQ in Golang.

https://opentelemetry.io/registry/?s=rabbitmq&component=&language=

What Should We Do?

To propagate context, we can use OpenTelemetry Propagator for both sync and async types of messaging!

Implement Custom Propagator for RabbitMQ

What’s Propagator?

https://opentelemetry.io/docs/reference/specification/context/api-propagators/

Propagator API is interface definitions for propagating contexts across process - how sender *Inject*s context into message and how receiver *Extract*s it from message. Propagator has Carrier which has a responsibility to actual injection and extraction from any type of messages.

Fortunately, RabbitMQ allows to put key-value format Headers in messages (docs), so we can use TextMapPropagator.

Propagator Implementation

Actually, since it is not Propagator but the Carrier that manipulates the TextMap, all we have to do is implementing the struct that satisfies the TextMapCarrier interface!

TextMapCarrier interface (doc):



type TextMapCarrier interface {

    // Get returns the value associated with the passed key.
    Get(key string) string

    // Set stores the key-value pair.
    Set(key string, value string)

    // Keys lists the keys stored in this carrier.
    Keys() []string
}

Carrier implementation for this interface (source code):



type AMQPCarrier struct {
    headers amqp.Table
}

func (c *AMQPCarrier) Get(key string) string {
    return fmt.Sprintf("%s", c.headers[key])
}

func (c *AMQPCarrier) Set(key string, value string) {
    c.headers[key] = value
}

func (c *AMQPCarrier) Keys() []string {
    keys := make([]string, len(c.headers))
    for k := range c.headers {
        keys = append(keys, k)
    }
    return keys
}

amqp.Table is just map[string]interface{} . Get() implementation is a little rough but it’s enough for example… ;)

Sender Side Implementation

At the sender side, we can inject context into header and just send the message (source code).



<span class="c">// Create an empty amqp.Tables</span>
<span class="n">headers</span> <span class="o">:=</span> <span class="n">amqp</span><span class="o">.</span><span class="n">NewConnectionProperties</span><span class="p">()</span>   
<span class="c">// Assign it to custom Carrier</span>
<span class="n">carrier</span> <span class="o">:=</span> <span class="n">internal</span><span class="o">.</span><span class="n">NewAMQPCarrier</span><span class="p">(</span><span class="n">headers</span><span class="p">)</span>
<span class="c">// Inject the context</span>
<span class="n">otel</span><span class="o">.</span><span class="n">GetTextMapPropagator</span><span class="p">()</span><span class="o">.</span><span class="n">Inject</span><span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="n">carrier</span><span class="p">)</span>
<span class="n">err</span> <span class="o">=</span> <span class="n">ch</span><span class="o">.</span><span class="n">PublishWithContext</span><span class="p">(</span>
    <span class="n">ctx</span><span class="p">,</span>
    <span class="s">""</span><span class="p">,</span>
    <span class="n">q</span><span class="o">.</span><span class="n">Name</span><span class="p">,</span>
    <span class="no">false</span><span class="p">,</span>
    <span class="no">false</span><span class="p">,</span>
    <span class="n">amqp</span><span class="o">.</span><span class="n">Publishing</span><span class="p">{</span>
        <span class="n">ContentType</span><span class="o">:</span> <span class="s">"application/octet-stream"</span><span class="p">,</span>
        <span class="n">Body</span><span class="o">:</span>        <span class="n">msg</span><span class="p">,</span>
        <span class="n">Headers</span><span class="o">:</span>     <span class="n">headers</span><span class="p">,</span> <span class="c">// Assign the context injected headers</span>
    <span class="p">},</span>
<span class="p">)</span>
<span class="k">if</span> <span class="n">err</span> <span class="o">!=</span> <span class="no">nil</span> <span class="p">{</span>
    <span class="nb">panic</span><span class="p">(</span><span class="n">err</span><span class="p">)</span>
<span class="p">}</span>
<span class="n">log</span><span class="o">.</span><span class="n">Println</span><span class="p">(</span><span class="s">"Message has been sent"</span><span class="p">)</span>

Receiver Side Implementation

Receiver side is the same.



    <span class="c">// Assign the received headers to custom Carrier</span>
    <span class="n">carrier</span> <span class="o">:=</span> <span class="n">internal</span><span class="o">.</span><span class="n">NewAMQPCarrier</span><span class="p">(</span><span class="n">d</span><span class="o">.</span><span class="n">Headers</span><span class="p">)</span>
    <span class="c">// Extract the context</span>
    <span class="n">ctx</span> <span class="o">:=</span> <span class="n">otel</span><span class="o">.</span><span class="n">GetTextMapPropagator</span><span class="p">()</span><span class="o">.</span><span class="n">Extract</span><span class="p">(</span><span class="n">context</span><span class="o">.</span><span class="n">Background</span><span class="p">(),</span> <span class="n">carrier</span><span class="p">)</span>
    <span class="c">// Generate child Span with received context as parent Span</span>
    <span class="n">ctx</span><span class="p">,</span> <span class="n">span</span> <span class="o">:=</span> <span class="n">otel</span><span class="o">.</span><span class="n">Tracer</span><span class="p">(</span><span class="s">"notification"</span><span class="p">)</span><span class="o">.</span><span class="n">Start</span><span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="s">"consume"</span><span class="p">)</span>

    <span class="n">msg</span><span class="p">,</span> <span class="n">err</span> <span class="o">:=</span> <span class="n">internal</span><span class="o">.</span><span class="n">DecodeNotificationMessage</span><span class="p">(</span><span class="n">d</span><span class="o">.</span><span class="n">Body</span><span class="p">)</span>
    <span class="k">if</span> <span class="n">err</span> <span class="o">!=</span> <span class="no">nil</span> <span class="p">{</span>
        <span class="nb">panic</span><span class="p">(</span><span class="n">err</span><span class="p">)</span>
    <span class="p">}</span>
    <span class="n">log</span><span class="o">.</span><span class="n">Printf</span><span class="p">(</span><span class="s">"received msg: %v</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">msg</span><span class="p">)</span>

    <span class="n">internal</span><span class="o">.</span><span class="n">CallServer</span><span class="p">(</span><span class="n">ctx</span><span class="p">,</span> <span class="o">&amp;</span><span class="n">client</span><span class="p">,</span> <span class="n">msg</span><span class="p">)</span>

    <span class="n">span</span><span class="o">.</span><span class="n">End</span><span class="p">()</span>

We’re All Set 🎉

Now, let’s start the apps and check the Jaeger UI endpoint (http://localhost:16686/).

By connecting the traces, we can now investigate any errors throughout the notification lifecycle easily.

Moreover, since the duration of the entire Trace is able to be measured, we can analyze bottlenecks of performance decreasing and notice slow notifications based on user experience.

I hope you learned something new from this post, please let me know if you have any feedback in the comments or Twitter!