Thanks for all replies. Actually the docs are good (imo) just these solutions proposed in docs are a horror.
Inside root folder of the module... so im unable to share packages between projects and code structure gets horrible, because now instead of nicely organized 2 levels of nesting i have 3 levels and i need to repeat name of the project 5 times inside every of 25 different root packages. Maybe for small apps. If i'm having eg. slab allocator used by both webserver and k-v storage it'd be good to put it outside and not having half of the modules in other apps imported from webserver and other half from k-v storage. It introduces unneeded complexity if package pretends to have something in common with something which is totally unrelated just because it's easier to put it in there. Next i'll have to do v2 of webserver when API of some of packages will change, so the version number won't reflect version number of my app... but changes to some single package in it. Putting main app dir/files as a parent of general purpose packages is a bad idea. Having tax app to be a parent of decimals package is like having a 3d graph library to be a parent of network I/O package. There is no relation so it should be separated for readability. >Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar ? I'll have to do hundreds of such edits and then re-edit it each time anything changes (package rename, moving files, etc.) My point is why this module approach broken the ability to organize code conviniently and logically... If we're in /src/foo and there is /src/bar and we do import "bar" in foo... it should just (what a surprise) import the local bar :D And another issue with this approach is that... should we put this abomination inside git? So really, everyone who downloads my code will have to waste 4 hours of his life replacing imports or he'll be forced to do edits inside C:\Users\slawomir\go or maybe he'll edit in F:\users\michael\my\nice\go\path and put it in repo so i'll have to change it back :D I know it's easier said than done but we have all this nice things like goroutines, GC, channels, peemption... and everything is so simple. Just to manually babysit package manager when previous model was working? Even having the user go to command line and issue module init for something without remote imports is a step backwards, because it's a waste of time, added complexity and totally unneeded. Having like tens of pages of "instructions" and blog posts telling users how to configure package manager just to run 10 lines of code if we want to organize it well is a step forward? With GOPATH you did one simple thing and it was working. Just once not 1000 times over and over, for each package or after anything in your dev enviroment changed. So not sure why everyone should be forced to migrate to this cumbersome model when we have nicely organized, self containted projects and the only issue is versioning for the PART of projects which are actually ... libraries, not applications. >One solution is apparently to use a module like a giant mono repo, aka gopath Still it requires for this replace and keeping absolute paths everywhere. It's not even possible to put your project on github this way because it won't compile without configuring everything. That's a huge regression because you'll have to copy-paste all shared code inside each individual app folder if you don't want to publish 30 packages as separate modules or put unrelated things together. Each solution is sub-optimal because separation can't just be done right in sane amount of time in this model because PM isn't able to conviniently handle local packages nor initialization nor changes in the packages... My point is, that it's so inconvinient that you'll organize your code badly just to save time... GOPATH is much better approach for bigger apps and it shouldn't be made obsolete. At least not if the only solution is putting things where they don't belong or setting up proxies to pretend local files are remote and then re-running some command line tools each time you add a line in one of these... środa, 7 kwietnia 2021 o 23:55:03 UTC+2 m8il...@gmail.com napisał(a): > >> https://golang.org/ref/mod > > The how to code docs need improving for packages but once you initialise a > module. You can create folders to hold different packages within the root > folder containing the .mod file. I'm not sure modules are not a regression > compared to gopath in some respects though? One solution is apparently to > use a module like a giant mono repo, aka gopath. I never used gopath > extensively myself. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/19859b0f-5c32-41a3-b0c6-bc6c1e48eb9en%40googlegroups.com.
