suggestion to use v prefix for tags

[kamilsk]

Hi! Based on this approach https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module to track tool dependencies for a module, as an example, I found a slight inconvenience when working with dsq, because dsq uses a different style to name tags. For go mod, it's recommended by this https://go.dev/ref/mod#versions

Each version starts with the letter v, followed by a semantic version

As a result, I have a pseudo-version like this instead of v0.21.0. It's challenging to understand which version is under the hood, actually. Is it possible to change the naming convention for tags?

[eatonphil]

Interesting but why are you importing dsq at all? It isn't intended to be a library.

[kamilsk]

I use it as a tool but use go mod to manage its version instead of https://github.com/multiprocessio/dsq#build-and-install-from-source.

[kamilsk]

Long story short. For example, I have a project where dsq will be helpful. I pack its tools together like this https://github.com/octomation/go-service/blob/main/tools/tools.go.

And use some magic

• https://github.com/octomation/go-service/blob/c1e6a708f6ac420de14981d812b03c46ed430aa0/Makefile#L333-L338
• https://github.com/octomation/go-service/blob/main/bin/activate

[eatonphil]

I have been wondering why the versions in go.mod are so ugly. I think I will adopt this v prefix.

However, embedded like this really isn't supported. I will probably remove the README note about go install. The problem is that go install ignores build tags and it is likely there will be build tags in the future.

You should only be using the binary installs or a dsq install script we eventually provide.

[kamilsk]

I think I will adopt this v prefix.

great, thanks!

The problem is that go install ignores build tags and it is likely there will be build tags in the future.

I'm not sure. As I see

The build flags are shared by the build, clean, get, install, list, run, and test commands:

• https://github.com/golang/go/blob/0c7fcf6bd1fd8df2bfae3a482f1261886f6313c1/src/cmd/go/internal/work/build.go#L59-L60
• https://github.com/golang/go/blob/0c7fcf6bd1fd8df2bfae3a482f1261886f6313c1/src/cmd/go/internal/work/build.go#L501

You could use something like this: go install -tags your-tag github.com/multiprocessio/dsq@latest. But I didn't test it.

You should only be using the binary installs or a dsq install script we eventually provide.

~Not all binaries are presented here https://github.com/multiprocessio/dsq/releases/tag/0.21.0, for example, there is no amd64 (or am I wrong?)~ UPD: sorry, I tested it on Intel and Arm, works well.

And as I see, brew uses go build https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/dsq.rb, it's the same as go install without some extra work

I have been wondering why the versions in go.mod are so ugly.

Me too, and now I know that go mod is sensitive to tag name :)