Add make update-go

[silverwind]

Add convenience command make update-go to update all go dependencies. updates now fully supports handling go dependencies.

[wxiaoguang]

It should use golang's go get -u ./...

It doesn't make sense to use a non-Golang-ecosystem update tool.

[silverwind]

go get -u ./...

The tool is much faster than go get and already in use for other dependency types. Also is supports a config file where you can lock/pin dependencies.

Nothing prevents you from using go get, this is mostly for me personally.

[wxiaoguang]

Nothing prevents you from using go get, this is mostly for me personally.

Then you can use Makefile.local

sinclude Makefile.local

[wxiaoguang]

The tool is much faster than go get and already in use for other dependency types.

If it is "faster", then it's likely that you skipped some steps, or package downloading. The "saved" time will be repaid later. Unless you 100% reproduce Golang's behavior, or directly call "go get -u", I don't see why it can be right.

[wxiaoguang]

Also is supports a config file where you can lock/pin dependencies.

The official approach to lock a package's version is using "replace" in go.mod

[silverwind]

If it is "faster", then it's likely that you skipped some steps

No, nothing is skipped. go get is slow because its conservative with parallel requests and waits longer for timeouts while polling major release version.

[silverwind]

Also is supports a config file where you can lock/pin dependencies.

The official approach to lock a package's version is using "replace" in go.mod

But that's inconsistent with js or python.

[wxiaoguang]

Also is supports a config file where you can lock/pin dependencies.

The official approach to lock a package's version is using "replace" in go.mod

But that's inconsistent with js or python.

I don't care about Golang packages should be consistent with js or python.

Golang syntax isn't consistent with js or python.

Golang go.mod isn't consistent with js or python.

Golang toolchain commands are not consistent with js or python.

I don't see why it should reinvent the wheels to manage Golang dependencies.

https://en.wikipedia.org/wiki/Occam%27s_razor

You can add a make target if you really need it and are going to maintain the dependencies, but I believe it can simply use go get -u with replace for version locking.

[silverwind]

I prefer one tool to manage all dependencies instead of having to deal with 5 different tools. Ultimately it will lead to me not being motivated to update go dependencies and we are already lagging behind on many. If you like to demotivate me, so do it.

[wxiaoguang]

I prefer one tool to manage all dependencies instead of having to deal with 5 different tools. Ultimately it will lead to me not being motivated to update go dependencies and we are already lagging behind on many. If you like to demotivate me, so do it.

I don't mean to "demotivate". At least, I think you can start using your tool to upgrade the go dependencies and prove that it really works, before introducing it without really using it.

[silverwind]

I don't feel like talking against a wall.

[wxiaoguang]

I don't feel like talking against a wall.

Me too, and I don't like fixing bugs for a wall.

[wxiaoguang]

update go #36546

You can see there are still problems when upgrading, I don't think your tool have handled it, or it's worth to spend time to fully reinvent a go get command in your tool.

go: github.com/go-ini/ini@v1.67.1: parsing go.mod:
        module declares its path as: gopkg.in/ini.v1
                but was required as: github.com/go-ini/ini
        restoring github.com/go-ini/ini@v1.67.0

And you can see upgrading blindly just fails, Golang ecosystem is not like JS ecosystem.

---

If you think I was "demotivating", feel free to edit that PR to handle these problems to show that your tool is right.