I'll try to make something interesting soon.
I'll try to make something interesting soon.
About the modules, those were very non-intuitive to me, coming from Python, C#, and JS. I think the official documentation from Go is not clear enough and has no simple examples...
After a few searches, I reached Stack Overflow and blogs with tips for Modules and subdirectories. Now, I can replicate an MVC model with templates.
This project helped a lot: https://github.com/J7mbo/go-subdirectories-with-modules
I got the fact that everything get bundled from a single folder but I too am used to properly specify what I want for every module since using Python/JS.
On my tries I managed to do local imports and compile with
GO111MODULES but I was confused on the uses of that flag. Online everything mentioned the url as a reference to the source and I was missing the point of using it locally from a single project.On a post the recommendation was to not use folder which is pretty bad in my opinion for a bigger project, also looking at yarn repo didn't cleared up my doubts (too big for me right now ๐).
Thanks again!
However, when it comes to nested modules, I believe the "prefix" path components must match the directory names or else Go won't find anything. So I recommend to always make the module name and directory name the same. That also puts much less cognitive work on yourself. :-)
Basically think of goroutines as lightweight threads.
Java does a good job here with the packages.
Go, when you develop outside the gopath, can get as you described, weird too
When defining a new package/library, run
go mod init git.mills.io/prologic/foo (_as an example_). This could also be github.com/prologic/foo or anywhere else with a publicly accessible Git source. I recommend this as the _easiest_ as things will "just work"โข.Next, never do development in
$GOPATH as this is basically deprecated and gone now. Always code outside of $GOPATH and use modules as per above.Finally if you are not ready to publish your work and you depend on
foo and bar and maybe something else too (_like Yarn.social's codebase_) then use $ go mod edit -replace git.mills.io/prologic/foo /User/prologic/Projects/foo (_as an example_).
When defining a new package/library, run
go mod init git.mills.io/prologic/foo (_as an example_). This could also be github.com/prologic/foo or anywhere else with a publicly accessible Git source. I recommend this as the _easiest_ as things will "just work"โข.Next, never do development in
$GOPATH as this is basically deprecated and gone now. Always code outside of $GOPATH and use modules as per above.Finally if you are not ready to publish your work and you depend on
foo and bar and maybe something else too (_like Yarn.social's codebase_) then use $ go mod edit -replace git.mills.io/prologic/foo /User/prologic/Projects/foo (_as an example_).
When defining a new package/library, run
go mod init git.mills.io/prologic/foo (_as an example_). This could also be github.com/prologic/foo or anywhere else with a publicly accessible Git source. I recommend this as the _easiest_ as things will "just work"โข.Next, never do development in
$GOPATH as this is basically deprecated and gone now. Always code outside of $GOPATH and use modules as per above.Finally if you are not ready to publish your work and you depend on
foo and bar and maybe something else too (_like Yarn.social's codebase_) then use $ go mod edit -replace git.mills.io/prologic/foo /User/prologic/Projects/foo (_as an example_).
When defining a new package/library, run
go mod init git.mills.io/prologic/foo (_as an example_). This could also be github.com/prologic/foo or anywhere else with a publicly accessible Git source. I recommend this as the _easiest_ as things will "just work"โข.Next, never do development in
$GOPATH as this is basically deprecated and gone now. Always code outside of $GOPATH and use modules as per above.Finally if you are not ready to publish your work and you depend on
foo and bar and maybe something else too (_like Yarn.social's codebase_) then use $ go mod edit -replace git.mills.io/prologic/foo /User/prologic/Projects/foo (_as an example_).
So, to understand the theory I started here
https://go.dev/blog/using-go-modules
And a few explanations in SO helped me to practice it in my project:
https://stackoverflow.com/a/57314494
Seems like it worked flawlessly, once I tried everything went in place.
The only thing I noticed is that the libraries didn't auto-installed like in the documentation, they say to run a
go get LIBRARY but after that it's all good.I have to try making something now.
go get ... or run go mod tidyโ -- Building won't install/fetch dependencies not already cached.
go get ... or run go mod tidyโ -- Building won't install/fetch dependencies not already cached.
go get ... or run go mod tidyโ -- Building won't install/fetch dependencies not already cached.
go get ... or run go mod tidyโ -- Building won't install/fetch dependencies not already cached.
go get and go mod tidy wont fetch new changes. that's all a manual affair AFAIK
go get and go mod tidy wont fetch new changes. that's all a manual affair AFAIK
go get -u ... that particular dependency.
go get -u ... that particular dependency.
go get -u ... that particular dependency.
go get -u ... that particular dependency.