Go Package Manager, Why bother for it?

I know the objetive of the Go package manager is somehow to be registry independant. But that is causing some problems, the most awful, no versioning, needing third party services to version Go packages, that’s the opposite we are looking for.

Before I met Go, I was (and I still be) a NodeJS lover. One of the things that makes me love NodeJS is NPM, the Node Package Manager, I found it to be a perfect tool. Then I wonder, if there is a tool, a package manager, that do its job perfectly, has a big community, etc… Why make another package manager? I really hate composer for PHP, and now I don’t see the utility of Go package manager.

I got an idea, I read about NPM limitations, what is the limit?, what cannot I do with NPM? Didn’t found nothing so…

Let’s try, let’s experiment:

Go Package with NPM

This post is not to change the roadmap of Go package manager, it is more about opinions of using NPM by your own. What do you think? what can go wrong?

1 Like

An interesting approach. EDIT: …for those who have NPM installed.

BTW, a native go dependency manager (that features versioning) is already in progress.

There have been a number of articles about the problem space recently, for example

which referred to the NP-completeness problem, described at

I wonder if trying to solve an inelegant problem will just be a pain for the Go and js communities…

There are elegant approaches: I promise to do a write-up when I regain some Copious Spare Time (;-))

1 Like

Just out of curiosity… why do you like NPM? Yarn is a bit better, but NPM has sooo many issues.

I smell a flame war about javascript package managers in a Go message forum.


I don’t mean to start a flame war or anything, it’s just that npm has given me nothing but trouble compared to package managers from other languages. It’s not nearly reliable enough for me to want to use it anywhere.

I’ve actually been warming up to the godep model recently, where you check everything in to your repo under /vendor. I always hated that before, but it definitely has some benefits - once you have the repo there are no external dependencies like network to contend with during your builds.

That being said, I am interested in dep, which may get the official golang blessing.

From a previous life (two, actually) I have reason to suspect that package management has version management as a corequisite: Russ Cox has demonstrated that the problem of package management is NP-complete in it’s absence, and in the two previous lives (Multics and Solaris) we carefully did both, so as not to inadvertantly fall into “DLL hell”. Subsequently, Linux has picked up the same technique.

So I think each language needs a package manger that can cooperate with the operating-system package manager and linker. It’s arguably a good thing if a language manager like npm could be language-agnostic, and serve js, go, java, fortran, and if necessary, lower canal Martian.

Next mesage: the writeup I promised.

I promised a writeup, so here it is, of “DLL Hell”, and avoiding an NP-complete problem in package managers

Closely related to, but not part of Golang Package Managers as such.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.