Skip to content

Blog

Working Dir in Std Os Package

Go standard library provides os pacakge to trackle with os related concepts, for example, the working dir. Working dir is a os level concept rather than a concept maintained by os package. Indeed, os package doesn't reinvent the wheel but rely on the operation system to tackle it.

Working dir is a concept for a process rather than an executable. So statement "the working dir of binary ./bin/server is ~/workspace/server" is totally wrong.

Get Correct Module Name via Trie-Style Structure

Go language supports to put modules under a VCS, such as github. Usually, one git repo contains one go module and multiple packages under this module. However, this is not always correct because Go allows you to put multiple modules under the same project, and Go helps to find these modules via its path. A typical example is repository go.opentelemetry.io/otel, which contains huge amount of modules.

In my real senario, given a list of used modules parsing from go.mod, and a package name retrieving from import declaration, I want to know which module does this package belong to. strings.Contain isn't help at all because module paths have overlapped a lot.

Go Minimal Version Selection Notes

This is a reading note to summarise the build list and dependency requirements of minimal version selection of go. If you want to learn more about minimal version select(MVS), please read the documentation and design docs below.

In short, MVS produces the build list as output, the list of module versions used for a build. The "minimal" in MVS means it selects the minimal version of each module that satisfies all requirements, instead of automatically choosing the highest available version. For example, if the requirements are "v1.1, v1.2, v1.3", the version v1.3 is the minimal version that satisfies all requirements. According to the MVS, v1.3 is selected.