Hi, I'm having trouble understanding and separating your core problems and what you are suggesting to solve them.
The solution to describe, sounds to me a lot like what `-mod vendor` achieves. I don't use that very often, so I don't really understand its shortcomings - so it might be helpful if you could describe the differences and what shortcomings of vendor mode you are trying to address. You also talk about onboarding - but I don't understand how the rest of your message relates to that. The replace-directive is an advanced feature that newcomers to the language don't need to be concerned with, as far as I can tell. It's really only useful to overwrite the dependencies of your dependencies with patched versions - which is pretty fickle and IMO not something newcomers should attempt. And they also don't need to a domain name in their module path - `go mod init foo` is all you need to start coding. Having a discoverable moudle path is only necessary once you actually want to publish it and make it discoverable to other people. This *is* indeed a bit of a learning curve, but note that other approaches also require you to set up code-hosting, for example, to make your code discoverable to other people. I think it's a fine onboarding-workflow to push code to github and learn that your code is now discoverable as `github.com/Username/project`. I don't think that's particularly easier or harder to communicate, than having to choose a globally unique name on crates.io (or wherever) and reference it by that. On Tue, Jan 12, 2021 at 11:41 AM Kevin Chadwick <m8il1i...@gmail.com> wrote: > I guess the point is that a domain is good for one scenario and env > variables > shouldn't need editing for GoPATH. If env editing isn't needed for go path > then they should be put on an equal footing, maybe GoPATH put back in primary > position. I've never really used GoPATH much but I'm not sure a vendor > folder > should be required. > I really don't understand what you are saying here. But FTR, I just tried, in a clean user (i.e. no environment variables set): mkdir foo go mod init foo And I could start writing code immediately. If you work locally then you have to manually edit the .mod files. For me > with a > replace directive to bring in general libraries. That is the likely > scenario of > a new user. I strongly disagree that a new user commonly or likely needs `replace`. Much less for common libraries. New users, most likely, will either a) work in an open source environment, in which they can just `go get` whatever library they need, or b) work in a closed source environment, in which they should use whatever workflow appropriate for their org. There is one relevant scenario, I think, which is an org wanting to newly adopt Go in a closed-source setting. I agree that there is friction here and a certain learning curve. The ideal solution would require setting up an internal module hosting solution - though, FTR, that internal module hosting solution can be as simple as an NFS share. Either way, `replace` shouldn't be a part of the solution *either way*. There is also the scenario where you have your code slit over many repositories and need to make changes to one, to change another. But IMO, this is a hairy problem in *any* language. I'd be interested to see, how other languages solve this better. > I have noticed that GoPATH is more prominent again in the docs. > > Generelly Gos docs and methods are far simpler and better than > Dart/Flutters but > in this regard. Flutter create followed by opening the folder in an IDE > with > import files as required, is a lot simpler. I believe they may have some > complex > cyclic dependency checking though. > > > FTR, I don't think what you are trying to solve here is a problem Jaana > is having. > > True, but I think maybe more pertinent to the issue of onboarding. After > all if > you are using Kubernetes, then you aren't exactly opting for simplicity > anyway. > > -- > 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/930e33cd-be9d-c2d7-bc8c-ffa84e66e234%40gmail.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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfET7KbgymkHkH0v6v--16JkBVv%3D8%2Bp76H4L9-PkU7PO4w%40mail.gmail.com.
