I agree w/ your basic premise, that modules are quite painful. However, after much trials, tribulations, and posting here, I received the solution that allows me to structure my code as before (and like you, all in ~/go/src). I only had to edit the import strings to reflect "src/mypackage" instead of "mypackage". That is, I just had to add "src/" to all of my import statements for my own code. I am able to leave the directory structure as is. I also had to set GOBIN
Look at the responses I received under the subject "package <whatever> is not in GOROOT <mailbox:///home/rob/.thunderbird/jt889mnb.default/Mail/Local%20Folders/Programming?number=42584820#group_thread_6> " You are probably frustrated for the same reason as I, ie, the documentation for module mode is not written for us dummies. I went over the docs and found them most unhelpful and needlessly complex. They fall into the category of "understood only if previously understood." Again, read the responses I received to my most recent thread, and you, too, will be ready to GO. *:-)* On Wednesday, April 7, 2021 at 5:31:07 PM UTC-4 Slawomir Pryczek wrote: > Hey Guys, I'm struggling with the new "modules" approach and after > checking several help files it seems it's inconvinient beyond belief. > Basically i have an app: > > ...src/ > /myapp/main.go package main > /pool/pool.go package pool > > And i can't even include package pool into main without manually > initializing module, then installing it, and then when i do any change to > pool i'll have to re-get / re-install the package, so it even breaks things > as simple as conviniently building a basic app with >1 shared package. > > Question is why it's no longer possible to break the project into > independent packages and easily re-use them. I have eg. a webserver which > implements each operation as separate package, and also it has slab > allocator which other projects are using. And it works great. > > Maybe someday i'd like to convert the slab allocator into separated > module, but why forcing users to do so much unnecessary work and pretend > everyone wants to expose everything they're writing as module from earliest > stage of the project? > > Is there any way to retain this kind of structure without countless hours > wasted on manually initializing modules and other completely pointless > maintenance tasks. Previously i was just able to create a package in gopath > and use it everywhere, refactoring was very easy and i could easily split > any project into multiple packages. Actually go was so good because > refactoring and reorganizing code was so easy. Now it seems that's no > longer possible and in docs I found info that gopath approach will be > obsolete, so i'm trying to go with the new one. Which seems so painfull... > > Also read several posts about local packages. Complexity of this is beyond > ridiculous. Really i need to install a local proxy or use some special > directives to allow my appa and appb to use packagec? Really it needs to be > so complex and so user unfriendly so instead of writing code we'll be > thinking about setting up proxies and configuring dependencies just to > share some code between 2 local apps because this has to be done via HTTP > or special configuration? > > Anyone has an idea for a reasonable solution which will allow easy > refactoring and code organization in packages, in this new model? > > Thanks, > Slawomir. > -- 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/e68eede7-5698-4ab2-aa21-805ea6ca8d00n%40googlegroups.com.
