can't disable auto upgrade go modules

[abdularis]

Is there a way to disable this behaviour since we prefer upgrading dependency manually that will allow us more control over unintended breaking changes?

Thank you

Tooltitude Version: v0.29.3

OS Version: Mac OS Sonoma

VS Code Version: 1.81.0

Go Version: 1.20.7

Code Repository (if open source):

What did you try to do?

Steps to reproduce

• Open Go Projects
• It automatically upgrades go modules dependency

[tooltitude-support]

Hi! Thank you for the feedback, and reporting issues.

What do you mean by automatically upgrading go module dependencies? I am only aware of us running go mod download to download missing dependencies. This might change go.sum file, in case it's not up to date. Do you mean change to it or something else?

P.S. Feel free to join https://discord.com/invite/f9MHBXsVwr to resolve the issues faster.

[tooltitude-support]

@abdularis If it's a change to go.mod, we could add an option not to download dependencies automatically (though, it's very useful). Otherwise, it's likely not us, but we will be interested in learning about how it happens.

[abdularis]

from the behavior it similar to running go get -u all which all upgrade dependencies to the latest version

[abdularis]

I'm not really sure here what tooltitude runs

[tooltitude-support]

@abdularis So which files are changed after running it? Is it go.mod? Or is it go.sum only? Also, did you try disabling tooltitude and seeing whether this behavior disappears after that?

[tooltitude-support]

@abdularis We added a tooltitude.downloadDeps setting which will be available in v0.30.0 (most likely on Friday), which will allow to disable downloading in case it's required for user or if it's useful for debugging problems like yours.

[abdularis]

go.mod and go.sum files both updated

[abdularis]

I have tried disabling tooltitude and it's not auto update anymore, Can't wait to try the new version 👍

[tooltitude-support]

@abdularis I wouldn't expect go mod download updating deps automatically. May be there's some inconsistency between versions there?

Another command we use is go work sync. Do you use go workspace?

We also use go list -m to get a list of all modules, but this should be strictly read only.

[abdularis]

Yes I'm using go workspace and have many go modules inside

[tooltitude-support]

@abdularis Could you run go sync workspace and check that the result is the same as with tooltitude?

[tooltitude-support]

@abdularis According to the documentation for the go sync command: https://tip.golang.org/src/cmd/go/internal/workcmd/sync.go it "Sync syncs the workspace's build list back to the workspace's modules". I.e. it looks, like there's an inconsistency between the module and workspace version. Also, this isn't the latest version, just the version from the go.work file.

[tooltitude-support]

@abdularis Also, this description doesn't look like the description of what we want to do to download modules, so we need to find something better. Module downloading is just a side effect.

[abdularis]

I ran go work sync it is the same result as it using tooltitude

[tooltitude-support]

@abdularis Ok. It looks like it's enough to invoke go mod download in the root of go workspace instead of running go work sync. So, likely in the next version you won't need to set the setting, but I will keep it just in case someone needs to debug dep problems.

UPD: I was wrong. The project which I was testing on, had just go.mod file and no go.work.

[abdularis]

@tooltitude-support You're right, so the issue is that I have different set of dependencies version all over modules in the same go workspace, therefore when I'm running go work sync it will make it consistent. Now that I'm fixing the dependency version it is not happening anymore when I'm using go work sync or using tooltitude

Thank you @tooltitude-support great work

[tooltitude-support]

@abdularis Ok. Found a better behavior. We will invoke go mod download for each module in the workspace. This should be pretty fast. Shelling out is a quite cheap operation. BTW, how many modules does your project has?

[abdularis]

Having options is good, I have around 50+ modules

[tooltitude-support]

@abdularis Thanks for the info. Also, really appreciate your help with hunting down this problem. We want to understand how folks use the product, and your help and feedback are invaluable here. If you have more problems or feature requests, feel free to submit them in issues, we will see what we can do :-)

[tooltitude-support]

@abdularis Our project has 5 modules and it is downloaded (with nothing to download) in 25ms, so for a project with 50 modules it might be around 250ms, which could be slower on slower machine, and we don't want this to become a startup bottleneck. So we will keep using go work sync for downloading, but will provide option (tooltitude.workspaceSyncForDownload) in case this behavior won't work for someone or to debug problems.

[tooltitude-support]

v0.3.0 out with the new option, so I am closing this issue.