How do you manage dependency versions in GoLang?

[idle skiff]

workspaces is the way to go

https://go.dev/doc/tutorial/workspaces

https://go.dev/blog/get-familiar-with-workspaces

[heady depot]

I think I see what workspaces are aimed to help with, but I think there's still something missing in regards of what I would like to do;

Go Workspaces seem similar to Python virtual environments, however what I am looking for is something more similar to the requirements.txt where you can specify the exact version of the library instead of fetching the latest

for example, if I run go mod tidy it will update the dependnecies to the latest version

which I don't want to do all the time; maybe I would want to update a specific library instead of all of them

and when someone pulls the project and tries to build/develop, I don't want them to accidentally pull the latest versions/versions that don't match the go.mod file

[idle skiff]

then do not do it all the time

[heady depot]

...

so how do i turn off auto update from go mod tidy

[idle skiff]

there is no automatic execution of that

[heady depot]

respectfully, i don't think you are understanding what I am asking

if i execute go mod tidy

that will update all dependencies

i don't want that

I want to be able to control which dependencies i update

[idle skiff]

people will do git pull && edit && go test && git push, CI will do git pull && go test

go mod tidy only rewrites the go.mod file, it does not commit it, it does not do anything else

it's up to you to see the differences and accept the changes, line by line or all of them altogether

[heady depot]

so if i want to develop a separate branch with a new version of a specific library

how do i get example.com/[email protected] from example.com/[email protected] without updating all libraries

before committing

if i want to run local unit tests

[idle skiff]

tidy is the automatic way to find the new available versions, nothing is enforced

[idle skiff]

you just update the one line in go.mod

[heady depot]

so you're supposed to manually update the versions in go.mod?

[idle skiff]

you can do it either manually or automatically, you have control either way

[heady depot]

the nothing is enforced is exactly what I am trying to deal with.

i don't care that it is not committed, yes we will catch that

but if someone is developing a branch

with a new version of 1 library

it seems like it is easy to accidentally update all libraries instead

either that or its really cumbersome to manage versions manually in go.mod

what is the equivalent of git submodules in golang; e.g. with git submodules you can specify a specific commit of the submodule you are importing and freeze it

so every time you pull the submodule it will pull that specific commit

then if you want to test a new version of the submodule

[idle skiff]

many people would disagree editing one line of a file is cumbersome

[heady depot]

you update the commit hash on the submodule on a feature branch

and it will freeze that submodule at that specific commit

[idle skiff]

workspaces is alternative handling of dependencies to external tools like git submodules

[heady depot]

sure, but tell me that again when you're managing versions between thousands of branches

[idle skiff]

I don't know about thousands of branches

[heady depot]

it is easier for us to manage if we can just enforce the versions all the time

its too easy to accidentally update everything

is my point

[heady depot]

workspaces seems more similar to virtual environments in Python from what i understand

it is not necessarily an equivalent to git submodules

[idle skiff]

right, running git mod tidy is easy, I won't discuss whether it is too easy or not

[idle skiff]

they are not

[heady depot]

it is easy at the moment, if you work on a monorepo/large scale project with hundreds of PRs every day it seems like it would be a nightmare

[idle skiff]

I do not think so

being large or not does not influence the dependency system, the numbers of PRs neither

[heady depot]

yes it does not, but it can make using the dependency system very frustrating at that scale

emphasis on can

maybe in your experience people manage dependencies much better than what I have seen

but that being said, i still think having a very convenient/easy way to update all dependencies can lead to accidents

which can cause larger issues/more headache when you are trying to merge multiple things at once

[idle skiff]

I think you are looking for a kind of control no generalist tool is gonna even try to provide

[heady depot]

what is why i am still asking

how do i freeze dependencies and only update one at a time

without manually editing go.mod

that seems very risky if you're not careful with your version strings

[heady depot]

i think a lot of other languages and tools can do what I am looking for

so i figure golang also has a way

[idle skiff]

go.mod file is not modified automatically,
dependencies are frozen as long as you do not modify the file,
updating one line in the file updates one dependency

[astral sierra]

go mod tidy doesn’t update anything if you haven’t changed go.mod first. you can have commit hook to prevent changing go.mod if you want and have say only dependabot update dependencies through PR reviewed

[cloud sigil]

Why is the original message deleted?