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/bb6d0bd0-e411-4c93-a1ee-5eec44e1bc48n%40googlegroups.com.
