justforfunc #42: Intro to Go Modules and SemVer

[@loveleshsharma9938]

I have read many articles on go modules but couldn't got clarity. After watching this video, its totally clear and i have understood the concept. Great video as usual.

[@FrancescoDonzello]

Awesome, Francesc. I had no time to look at the proposal and in just 30 min you explained how Go Modules work. Thank you!

[@taylormonacelli]

Very helpful seeing the errors along the way and how to fix each step. Super stuff!

[@naysolange]

simple y práctico! I've read articles about go modules but with this explanation I've understood it definitely. Thanks for the video

[@mikjson]

Great video and introduction! Added a link to this video on the Go Modules wiki page in the Introductory Material sub-section. :-)

[@nengsite]

the best golang channel.

[@riskyferyansyahpribadi6984]

this channel very good when explaining about go modules.

[@markuswerner1166]

Thanks for this Video. I started with go in August 2018 (go 1.10) and read / watched as much as possible about the history of go. I've read the blog post about "go modules", some more Webpages and watched diffrent Videos about it - Same for SemVer. You bring everything to the point. I'ved development my Adminscripts and some small apps not in GOPATH. Since they were small enough I didn't had trouble with GOPATH at all. I'm in a portable enviroment so I have to use on a network share and set GOROOT = GOPATH (Didn't know it better at that time). I should have splitted it in the first place anyway, cause Versionupgrades are more complicated. But go modules to the rescue, I won't be bothered with it anymore. Currently I think I will stay with the method to have every project in independent directories. I asked my self if it is still a good Idea to split GOROOT and GOPATH cause of the modulecache GOPATH/pkg. What do you think ?

[@ultiumlabs4899]

this video still relevant in 2021. thanks.

[@pulkitkathuria9448]

Thank you. This is by far the best tutorials on go on youtube. Would you be able to address on how to handle when a git repository is removed, force pushed or renamed. More interested in knowing the good practices that we can follow. Like pushing the vendor folder, keeping a local copy of module somewhere?

[@tomah911]

Thanks for the video, really clear explanations !

[@julienlevesy3790]

Dramatic look gopher, made my day !

[@eaglesongs]

Awesome and helpful video. Thanks! @23:25 when cloning embedmd, the latest version actually already contains go.mod and go.sum, just FYI.

[@JustForFunc]

I don't think so, no. Unless you mean when you clone it now.

[@eaglesongs]

Yes I meant when following along now...

[@JustForFunc]

@@eaglesongs Hah, yeah. Of course now embedmd is a module like all good Go package should do 😎

[@ovidiub13]

29:27 you can just do: «grep -R *» and it will have the same result, but it's quicker to type.

[@yf4453]

Finally we have hermetic builds!

[@skwtf]

Thanks for the video. I didn't understand if modules are a best practice or should be used only if you have dependencies? For example if I have a simple script, that uses only built in Go packages - do I need to use modules?

[@realB12]

Excellent Tutorial. Phantastic Speaker! Let me know where I can donate some bucks!

[@xyzale]

Very good explanation, thank you!

[@arhyth]

this was really helpful! i tried reading golang modules doc but found it too dense for a noob given a "legacy" codebase just trying to add and test a small piece of code.

[@manikanth2166]

Both golang and node.js had the same problem in versioned dependency resolution. And it looks like go borrowed heavy inspiration from node as both maintain hash to point to the dependency version. It's package.json and package-lock.json ressemble go.mod and go.sum files here.

[@ankitagarwal655]

Love Your Every Video :-)

[@hcblue]

This was so useful! Thanks, Francesc!

[@David94305]

you are a beast man, great work

[@makkalotify]

This was very useful, thanks !

[@paracha3]

Very informative. Please keep it up

[@manosragiadakos3928]

is dep going to be replaced by go.mod in the future ?

[@trexiath]

Yes

[@JustForFunc]

What Tom said!

[@attilao]

Interesting to see that while Go package versions should start with "v", Go itself does not seem to start with "v". When you typed go version, it printed "go1.11.2".

[@quillaja]

So this is the "official" version of vgo? Thank you for another quality video!

[@tejinderkaur2120]

My package exists at [/root/go/src/myProj/drivers/myPkg] in GOPATH (/root/go) I am importing it in /root/go/src/myProj/myComponent/xyz/abc/server.go but I get the following Error: package myProj/drivers/myPkg is not in GOROOT (/usr/local/go/src/myProj/drivers/myPkg) Why is it not checking the GOPATH location?

[@ntrrg]

Thanks! this is a great explanation (and demonstration) about that concepts. 29:30 You may also use grep -r github.com/Sirupsen/logrus **/*.go

[@askwgh]

Thank you so much. It is so helpful.

[@joonasfi]

Thanks for this introduction to Go Modules! You earned a subscriber. I am currently using Dep and am waiting for the stable Go Modules version of before I migrate all my projects. Can I suggest that if it's not too troublesome, publish the major subject timestamps in the description? I wanted to skip directly to the Go Modules part because I'm already familiar with SemVer. BTW it's awesome the way you pronounce "module" :)

[@cristianocolangelo7745]

Do I still need to use Go modules if I'm just creating a standalone application (so no outside imports) living inside gopath? Or should I do that as a best practice?

[@antanaskiselis7919]

How does it solve dependency conflicts, like depending on different version of the same thing? Or each module is an island on it's own?

[@GerardoOscarJT]

Hi Campoy! Thanks for your video. With modules, is still possible having the vendor directory to commit all dependencies?

[@johnmackenzie534]

How would this work with an api codebase? Do I still use modules for the bigger Go codebases or are they only for packages/libraries?

[@pohjoisenvanhus]

Just wondering how going outside GOPATH will affect using guru. Does guru find imports that are outside GOPATH?

[@mnfchen]

Great video! Very quick follow-up questions: 1. Can your go module depend on non-modules (i.e. they don't have go.mod)? In other words, can you depend on something that isn't semantically versioned? 2. How do you set the semantic version of your module? Through git tags? In go.mod?

[@greiezer]

1.) depending on code that does not yet define go.mod files will result in v0.0.0-git-latest-commit-hash as the version, e.g. golang.org/x/crypto v0.0.0-20181025213731-e84da0312774 see go.googlesource.com/go/+/refs/heads/master/src/go.mod

[@Goodvvine]

Is the vendor directory updated when you update your dependencies? or do you have to run `go mod vendor` again?

[@mekegi]

not autonatically. every time you need run `go mod vendor` But if your IDE has support of `go modules` you don't need vendor folder github.com/golang/go/wiki/Modules#what-is-the-status-of-module-support-in-ides-editors-and-standard-tools-like-goimports-gorename-etc

[@TristanColgate]

If you do another vide on modules it might be worth mentioning that backward compatability doesn't count for v0.x.y. I hadn't really heard it said much and it came as a suprise when I first heard about it.

[@RomsyYoutube]

Thanks for great videos, keep it up :D

[@Oswee]

:( stepping into bit more advanced workflow and found all this go modules thing bit confusing. Like... i am working on some nested module (monorepo) in separate branch... made some protobufs, later updated those and then in the same branch i want to use those updated protobufs, but i can't because my imports are pointing to previous version of protobufs. Its just becomes really messy to keep in head all this stuff.

[@androth1502]

so this is like a more obfuscated and complicated implementation of rust's cargo?

[@shadowfaxenator]

How to correctly change module name and repo it is stored ? For example if I want to start with github and then replace with gitlab

[@robinlemagnifique2778]

Thanks for the video! Not sure to understand the last part with the S/sirupsen issue, I was expecting some magic there but in the end you have to manually change the import in the vendors, so what's the point?

[@JustForFunc]

The point is that code used to work, but doesn't anymore once you start using modules. So it's good to know what the message means and how to fix it

[@julian7]

@@JustForFunc if you look at 26:27, github.com/Sirupsen/logrus v0.0.0-20170706134407-59d0ca71e5fa was included in the original repo. At some point of time (see github.com/sirupsen/logrus/pull/384) the package has been renamed from github.com/Sirupsen/logrus to github.com/sirupsen/logrus. This causes extra issues on case-insensitive systems like MacOS and Windows.

[@gregfrllo]

i think i'm falling in love

[@cdromhelp]

Hey. Is it possible to use versioning in import block? For instance package pack1 import ( "github.com/noname/superpac v1.2.3" ) package pack2 import ( "github.com/noname/superpac v1.4.3" ) package pack3 import ( "github.com/noname/superpac v2.2.3" )

[@JustForFunc]

Nope

[@MrLucevers]

Thanks!

[@alskidan]

I'm confused. semver.org/spec/v2.0.0.html says nothing about "v" prefix. It seems to me that "v0.1.0" is not semver compliant, but "0.1.0" is.

[@JustForFunc]

That's why I said "in Go", yeah

[@kalyan120]

This is cool. Great video on a much needed feature. Would it be a best practice to check in the go.sum file as well?

[@JustForFunc]

Yeah, I mention it at some point. It should be added to your git repos.

[@piyushchugh6148]

7.40 is the part you should jump to if you want to directly learn to code around Go Modules and skip the Modules and SemVer theory part.

[@sarvsn9125]

Hi thank you for the video it was quite informative . Currently we are using go with oracle. We are using go-oracle which uses C code, I know mod does not copy the non-go code in the vendor directory. Due to this my compilation breaks. Is there a way to handle such a situation?

[@JustForFunc]

You might want to ask this in golang-nuts or the gophers slack channel

[@mishasawangwan6652]

thanks great video

[@hackdan]

Thanks, please review gorm vs other vs native

[@manikanth2166]

Looking for a video on syscall. How those systemic specific packages went out of go main repository. How to rightly use them? And an example of cross platform build (mmapped i/o on linux vs windows).

[@assaf6142]

How to use a dependency which doesn't use go modules? Can I specify "latest" in go.mod for one of my dependencies?

[@JustForFunc]

If you try it you'll see go.mod will use the commit hash instead of the tag Not sure whether latest exist or whether it's a good idea ... at that point you might as well not track dependencies

[@assaf6142]

​@@JustForFunc Thanks :-)

[@borislenzinger8907]

Hi Francesc, you say in the video that you would be happy to run your workshop in a conference. I'm part of RivieraDev organizers and I would like that you apply in the CFP for a Go workshop. How can I get in touch with you to talk about this ?

[@JustForFunc]

Easiest way is [e-mail]

[@borislenzinger8907]

@@JustForFunc Sent ! Thank you ! :-)

[@ovidiub13]

You can just use apt instead of apt-get when you run it from the prompt. It's shorter and it's a single command for multiple actions. The apt-get, apt-cache, etc are still to be used when scripting for clarity.

[@ehsanranjbar6571]

If i create a module with name foo and upload that to github.com/ehsanranjbar/bar How should i import that and how go mod can find repo?

[@Euryugasaki]

I dont really understand why we still need to use "go get something". How about "go mod get" "go mod remove" "go mod update path@specific_version" "go mod downgrade path@specific_version" and so on? It makes everything stick to "go mod" instead of two type of command.

[@JustForFunc]

Why "go mod get" when "go get" does the trick?

[@EnricoCandino]

How do modules work with cross-dependencies? For example, if I am using foo/goofy and bar/mickey, and they are both using mylib/common but with different version of it? Probably the "not vendored" version could work since they are probably referencing different things under the pkg/mod directory, but how the vendor folder will be?

[@kalekold]

The lowest version that satisfies both is used.

[@JustForFunc]

answered on twitter! twitter.com/francesc/status/1063180187251044352

[@Medardusai]

In the same major version the lowest satisfying version will be used. For different major versions the packages will be handled as different packages. Cox' blog has a good entry on it, I think this is the correct entry: research.swtch.com/vgo-mvs

[@licoresse]

Semantic versioning has been fundamentally broken since its inception.

[@JustForFunc]

Why? You can't simply drop statements like that without a justification

[@mearpitjain09]

Wasn't this published earlier ? 🧐

[@JustForFunc]

earlier than ... ?

[@akshaynaik4888]

nice as all your videos, but can you make explicit video on only go modules more simplified without semver etc

[@JustForFunc]

@@akshaynaik4888 go modules is all about dependencies and versioning, so ... no

[@akshaynaik4888]

@@JustForFunc okay,😊

[@sunilk9760]

millitary standard mike

[@starllama2149]

Lmao this guy loves golang

[@jazzochannel]

What is a reposiry? Is it similar to a "repo"? I think you forgot and transposed a couple of letters there.. reposiry repository hm.. levenshtein difference of 2... compiler-brain says: DOES NOT COMPUTE reposi__ry repository you need to enunciate those two sounds.... tee, ooo do you see how what you are saying is different from the dictionary defenition? re-po-si-to-ry re-po-si-ry So no, I was wrong, you didn't transpose anything, you just skipped two letters. Maybe not a big deal, but it is surely funny :) I am going to test this out on my co-workers. REPOSIRY! or even RESORY or even RESY. I am sure they are smart dudes and will understand what a RESY is ;)

[@JustForFunc]

*definition

[@VictorZamanian]

Repossery? Are you trying to say "repository"?

[@JustForFunc]

Are you trying to say "thanks for the video"?

[@theocrevon6374]

Are you trying to be a dick?