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 :DI 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 gopathStill 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...
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/85a8cb0c-75c6-4e1c-ba12-a4bcd44ee494n%40googlegroups.com.
But what if you don't even have a domain for your source code? Sure you can use a fake domain like "foo.example"
and then use replace, and then remember to not commit the replace because someone else may have the code in a different location, etc etc. Imagine if it was the other way around:
my_source_location/
ProjectA/
go.mod
module ProjectA
replace /home/nick/src/ProjectA => mydomain.com/group/ProjectA
ProjectB/
go.mod
module ProjectB
replace /home/nick/src/ProjectB => mydomain.com/group/ProjectB
On Thursday, 8 April 2021 at 12:48:28 UTC+2 nick....@gmail.com wrote:But what if you don't even have a domain for your source code? Sure you can use a fake domain like "foo.example"It doesn't have to be a fake domain name, just a module name, e.g. "foo".
and then use replace, and then remember to not commit the replace because someone else may have the code in a different location, etc etc. Imagine if it was the other way around:
my_source_location/
ProjectA/
go.mod
module ProjectA
replace /home/nick/src/ProjectA => mydomain.com/group/ProjectA
ProjectB/
go.mod
module ProjectB
replace /home/nick/src/ProjectB => mydomain.com/group/ProjectBIf you're only tinkering without publishing you can put the go.mod directly under "my_source_location", then you have your own GOPATH-like environment.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/57f57bcf-2c13-4a98-936f-8f7f54b4351en%40googlegroups.com.
In my case, we have an internal git server at work that we just access over ssh. We have a few dependencies between repositories and a few developers working on the same repository. I'm assuming this is a rare scenario, but it is one use case that I think modules have made the work flow more inconvenient.
----
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/57f57bcf-2c13-4a98-936f-8f7f54b4351en%40googlegroups.com.
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPKajN6Q5AomVmSZyGX_EqUn0D22KandwGviOxZW6Xi1_vAWSg%40mail.gmail.com.
A replace in the go.mod file is of no help here because I still have to specify a require with a concrete version or commit hash for the library. This means I cannot just change the code in the library module, I also have to create a commit and check it in, then go back to my main module and udpate not only the replace but also the require in go.mod, every time I want to simply place a simple, temporary print statement for debugging purposes into the library.Does anybody have an easy workflow for the common use case?
A replace in the go.mod file is of no help here because I still have to specify a require with a concrete version or commit hash for the library.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/421ae2eb-fd97-46b4-ab83-979c5e63cf88n%40googlegroups.com.
.
├── projectA
│ ├── go.mod
│ └── main.go
└── projectB
├── go.mod
└── lib.go
// projectB/lib.go
package projectB
import "fmt"
func Foo() {
fmt.Println("ProjectB")
}
// projectB/go.mod
module mydomain.com/projects/projectB
// projectA/main.go
package main
import "mydomain.com/projects/projectB"
func main() {
projectB.Foo()
}
// projectA/go.mod
module mydomain.com/projects/projectA
require mydomain.com/projects/projectB v0.0.0
replace mydomain.com/projects/projectB => /tmp/gotesting/projectB
Does anybody have an easy workflow for the common use case?
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/_BqV6Rk15UA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.