I must admit, module management in go is still a torture, I haven't had
worst experience yet, I'd spend less time programming my own language, also
the type system is still quite primitive and the syntax feels outdated.
On Tuesday, April 20, 2021 at 8:33:26 AM UTC+2 Johann Höchtl wrote:
> This
This sounds like it would warrant a howto go modules blog post. Thank you
for sharing your experience.
michael...@gmail.com schrieb am Samstag, 10. April 2021 um 02:20:54 UTC+2:
> FWIW, I completely agree with the sentiment that confusing documentation
> has created pain and unnecessary
FWIW, I completely agree with the sentiment that confusing documentation
has created pain and unnecessary difficulty for solo developers. I try to
keep in mind that Go was developed for use by large teams working on
million line programs and that I'm lucky to be able to piggyback on the
Dnia 2021-04-07, o godz. 14:31:07
Slawomir Pryczek napisał(a):
> Anyone has an idea for a reasonable solution which will allow easy
> refactoring and code organization in packages, in this new model?
Idea is here: https://github.com/golang/go/issues/44347
Whether is it reasonable or not —
Thanks for the help, so i think i get it fully now.
@Nick: Sure works great if you're making a project with github modules.
Having local modules is possible. But so cumbersome people would be
occupied with managing files rather than writing code (if you have >20 of
them).
@Carla: Actually i
> >>One solution is apparently to use a module like a giant mono repo, aka
> >>gopath>
Still it requires for this replace
You do not need replace, unless you are amalgamating multiple modules.
You can just create a folder named e.g. library with a .go file; package lib
Then in your other
On Thu, Apr 8, 2021 at 1:49 PM Nick Keets wrote:
> 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
On Thu, Apr 8, 2021 at 2:08 PM 'Carla Pfaff' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> 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"
>>
>
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
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
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
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
>
>
> 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
Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar ?
https://golang.org/ref/mod#go-mod-edit
On Wed, 7 Apr 2021 at 17:31, Slawomir Pryczek wrote:
>
> Hey Guys, I'm struggling with the new "modules" approach and after
checking several help files it seems it's inconvinient
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
15 matches
Mail list logo
