(#pysczza) @justamoment I haven't touched the goroutines yet (I played with these like 10 years ago), but I haven't found a case where I need these.
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:
matched #k4wje2a score:11.38
Search by:
Search by 1 mentions:
(#pysczza) @eaplmx Thank you so much.
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!
matched #jf6c5hq score:11.38
Search by:
Search by 1 mentions:
(#pysczza) @justamoment @eaplmx Modules are a bit weird, indeed. In fact, you can name your module differently than the directory name. To the extreme, you can have a directory "foo", but call the module "bar" and call the "bar" directory your module "foo". Not sure why anyone wants that, but there you have it.
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.
matched #vygivsq score:11.38
Search by:
Search by 2 mentions:
(#pysczza) @lyse this is what confused me the most. But also Python is confusing in this case.
Java does a good job here with the packages.
Go, when you develop outside the gopath, can get as you described, weird too
matched #aji72va score:11.38
Search by:
Search by 1 mentions:
(#pysczza) @carsten So I wanted to reply to this Yarn with some comments, but wasn't able to _really_ do so whilst out 'n about camping with the family 😅 -- Basically Go's modules (_the more recent version_) is actually pretty good. Let me try to help you understand the basics of it...
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_).
matched #m3kkjwa score:11.38
Search by:
Search by 1 mentions:
(#pysczza) @prologic I'm missing something here, does this allow to remap a local module with it, or is just a reference for the whole project/module locally?
matched #5ut5hqq score:11.38
Search by:
Search by 1 mentions:
(#pysczza) @justamoment I found that part is well documented 🙂
So, to understand the theory I started here
And a few explanations in SO helped me to practice it in my project:
matched #ckyzuxa score:11.38
Search by:
Search by 1 mentions: