I think the problem is that this process is inconvenient, not that it is
not possible.
Modules work great if you publish everything on GitHub, or something
similar. 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
It would still be possible to publish your project, you'd just have to use
the replace line and remember to not commit it. Would it be fair if people
complained about it?
On Thu, Apr 8, 2021 at 6:07 AM Justin Israel <justinisr...@gmail.com> wrote:
>
>
> On Thursday, April 8, 2021 at 12:14:40 PM UTC+12 Slawomir Pryczek wrote:
>
>> 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...
>>
>
> My take on this is that you appear to be aggressively ranting about
> modules with assertions about how it does or does not function, before
> actually discovering what modules truly do or do not do. People are more
> likely inclined to be helpful if you just present your situation, what you
> tried, and what you expect. But leave out the bits where it is assumed to
> be a broken implementation that can not do what you want, that it is poorly
> conceived, and how frustrated and angry those assumptions makes you feel.
> Your frustrations are valid, but they are likely based on incomplete or
> wrong information.
>
> So to me it sounds like there could be a mix of misunderstandings about
> modules, and maybe some things modules actually don't do, with regards to
> your expectations. Given ProjectA and ProjectB, sitting in whatever
> location you prefer on you filesystem, you should be able to use the
> "replace" directive to make ProjectA use the local ProjectB without the
> need for pushing any changes to an external source control or installing
> any kind of local module proxy server.
>
> my_source_location/
> ProjectA/
> go.mod
> "module mydomain.com/group/ProjectA"
> "replace mydomain.com/group/ProjectA =>
> /path/to/my_source_location/ProjectB"
> ProjectB/
> go.mod
> "module mydomain.com/group/ProjectB"
>
> Changes to ProjectB should be immediately available when compiling
> ProjectA.
> Yes you are correct that the go tool does not try to do a kind of local
> path lookup if your ProjectA has 'import "ProjectB"' and ProjectB happens
> to be in a directory relative to the directory containing ProjectA. Yes it
> would have found it under the GOPATH mechanism if the projects lived
> immediately under your GOPATH, but that is not a flexible approach when it
> comes time to deploy you ProjectA, and it expects ProjectB dependency to
> live under a users GOPATH.
> The module approach is quite easy when it comes to achieving local
> development, since your source code stays the same with correct qualified
> import path strings, and should a developer want to hack on a dependency,
> then they can just add a "replace" directive to the go.mod.
>
> Now given a number of packaged within the same module, this should not
> require any special handling. All packages under a single module will all
> build locally. If you have a package within a module that is trying to pull
> from an external source control, then something is wrong in the project
> structure.
>
> I feel that if you can end up getting to a point where you fully
> understand the features of Go modules, that you will find them superior to
> the GOPATH mechanism.
>
> Justin
>
>
>
>> ś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/85a8cb0c-75c6-4e1c-ba12-a4bcd44ee494n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/85a8cb0c-75c6-4e1c-ba12-a4bcd44ee494n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPKajN7HvkFwbEYqXUpQ7MahMPtk62tu6t1TZ%2BwMWw3Hx4ZinA%40mail.gmail.com.
