update go

[wxiaoguang]

Just a demo for #36541. Can be closed if no progress.

[silverwind]

The problem with go get is you can not exclude certain dependencies, for example when they contain incompatible breaking changes etc. A replace statements is not a full replacement when you want to pin to a certain semver range for example. While rare, a module could be releasing versions at both v1 and v2 tracks, for example. updates offers a pin option for that.

But we can still merge this as this is better than not having a update-go.

Actual dependency changes should be reverted, we have #36548 up.

[wxiaoguang]

A replace statements is not a full replacement when you want to pin to a certain semver range for example. While rare, a module could be releasing versions at both v1 and v2 tracks, for example. updates offers a pin option for that.

This update does include a "pin" requirement, I have made some changes to make the code compile in another branch but not here.

Using replace in go.mod is the only correct approach.

If you think your tool can handle it, just do it. Show the code.

[silverwind]

If you think your tool can handle it, just do it. Show the code.

In updates.config.ts:

  pin: {
    "github.com/foo/bar": "^5.0.0",
  },

[wxiaoguang]

If you think your tool can handle it, just do it. Show the code.

In update.config.ts:

  pin: {
    "github.com/foo/bar": "^5.0.0",
  },

No, it won't work for Go dependency problems. Show your change in this PR

[silverwind]

I don't understand what you want. In any case, revert the dependency updates here please.

[wxiaoguang]

I don't understand what you want. In any case, revert the dependency updates here please.

I would really suggest you first spend enough time on maintaining Golang's related packages before reinventing your wheel.

You just never really handled the complete go.mod upgrade, but just imagine that "it should be like that".

You can check the change here: https://github.com/wxiaoguang/gitea/tree/temp-fix-go-dep , in this case, go.yaml.in/yaml/v4 should be locked, it is a dependency's dependency.

---

In any case, reinventing a tool which isn't necessary is not a right practice. You can't just say "it looks faster" or "it manage locked packages together" then introduce a untested toy into a production repo, actually Golang go.mod doesn't work that way.

This is my final conclusion for this problem.

[wxiaoguang]

Actual dependency changes should be reverted, we have #36548 up.

#36548 has been merged, it upgraded some packages which don't cause problems. This PR has been rebased on main branch.

Now, the remaining/renaming packages, challenge work, if you'd like to try, feel free to. Or maybe I can handle it one week later.

[silverwind]

Another feature that go get lacks is import path rewriting, I will soon add it to updates.

[wxiaoguang]

Another feature that go get lacks is import path rewriting, I will soon add it to updates.

That's not how go.mod works.

[silverwind]

Another feature that go get lacks is import path rewriting, I will soon add it to updates.

That's not how go.mod works.

If you use go get to update to new major versions, the code will no longer compile. It's a inherent flaw in the go get method imho.

[wxiaoguang]

I don't understand what you are talking about. You are just guessing and imagining.

You have never really maintained the Go packages or dependencies. It’s like someone on the street runs up to you and says, “Scalpels are terrible. I modified a kitchen knife myself—let me use it to perform brain surgery on you.”

[wxiaoguang]

If you are not able to make this PR compile with proper dependency management, don't talk with me about this topic.

You can learn about how to use replace to lock a package's version (#36546 (comment)), how Golang resolves dependencies for different packages and resolve conflicts, why yaml/v3 and yaml/4 should co-exist, etc.

[silverwind]

Aren't replace directives a bad practice because it's not obvious to the code reader what the actual version in use actually is? Say you load module/v2 in code but the go.mod replaces module/v2 with module/v3. A reader could think the code still uses v2.

I think it's bad practice to use replace directives for major version upgrades and it's much better to rewrite import paths in **/*.go after major upgrades, and go get -u can not do this so your update-go task is incomplete.

[silverwind]

Not needed, tidy already updates the license file

[silverwind]

I can accept the current version with go get, it's better than nothing.

[wxiaoguang]

I can accept the current version with go get, it's better than nothing.

You can also make the code compile to show that you really understand how dependency works.

[silverwind]

I'm of the opinion that replace statements are dirty and should not be used. It's basically the same story as package.json overrides which is also dirty.

If you want a specific depdency version, specify it directly, no need to add needless indirections to the dependency resolution like replace or overrides.