I am creating a library/package that has an example URL of github.com/devdev/awe_some. If a potential user were to use this package, they would automatically have to us awe_some.Api() which looks ugly with the underscore. Is there something in the awe_some go.mod file that I can add/edit to have awe_some be imported as awesome without the user having to explicitly declare that?
#Providing package with different module name?
broken bough
trim prism
i don't think so. Can i ask why not just name the repo devdev/awesome?
vocal aspen
as a user of it, you can also alias the import as something else if it's a big issue 
broken bough
well it was an example, perhaps the name of the project wouldnt make sense as one word but rather two for whatever reason.
trim prism
gotcha. Yeah I don't think there is a way to have it auto-import with another name. Users would have to declare it, as you stated
broken bough
so what if the module in the go.mod was github.com/devdev/awe_some/awesome ?
pulsar garnet
well it was an example, perhaps the name of the project wouldnt make sense as on...
I'm not sure how specific you are trying to be with this statement but the name of the project and the name of the package need not be the same
if there's a suitable alias, there's a suitable name
broken bough
well im trying to learn go patterns for modules and naming things. I have been writing my own applications for a while not distributed libraries so I am trying to learn more about the module system. Mainly how the declared module in the go.mod file translates to imports in other projects
So going back a bit, if I were to have a flat structure in the root dir and the package was github.com/devdev/awe_some could I declare the module as github.com/dev_dev/awe_some/awesome or does it have to match the path exactly?
I am guessing by https://go.dev/doc/modules/gomod-ref#module that it has to be the exact path
pulsar garnet
So going back a bit, if I were to have a flat structure in the root dir and the ...
you are conflating module and package names, perhaps it would be clearer to look at something specific, see for instance https://github.com/hashicorp/go-multierror/blob/main/append.go
I picked it at random because it illustrates your situation
broken bough
ahh yes that was going to be my next question. the root package in this situation could be awesome while the module would be the github path and importing would result in github.com/devdev/awe_some/awesome?
broken bough
right, but like in the example you shared, since the root files declare a package with the prefix go_ like the module, then the import would be github.com/user/repo/package
pulsar garnet
since the root files declare a package with the prefix go_
but they don't
am I misunderstanding what you mean?
the root package lives at github.com/user/repo regardless of what either is named
if it's the root package, it lives at the root
broken bough
Ah I just learned something (through testing my self). When I have go files in the root directory of the module, and the package is declared as something other than the module (ie. awesome instead of awe_some) the import is automatically aliased when imported in another package. This is what I was trying to achieve.
pulsar garnet
fundamentally an import path and a package name are dissociated, that's why you have package declarations
now, it's a good idea to keep them the same for consistency, or as close as possible when there are other needs that must be satisfied (such as go-multierror)
pulsar garnet
Ah I just learned something (through testing my self). When I have go files in t...
ish
broken bough
lol, love 'ish', and ya the only reason I would change the root package is for reasons like go-multierror or awe_some situations.
pulsar garnet
what you are observing is gopls adding an alias because the last path segment is a valid package name, but it does not match the package declaration
broken bough
aweee interesting, so really, it doesnt matter what the root package is, its referenced by the module path regardless. Making sense
pulsar garnet
ie, it will not do so for go-multierror because go-multierror is not a valid package identifier
it would for go_multierror, given it is a valid identifier but the actual package name, which is what really matters, is multierror
edit: this is partially incorrect, as it stands it has hardwired logic to trim the go-
broken bough
Makes sense, I learned a lot here, thanks
pulsar garnet
but it's the language server (or one of its sub tools) that's deciding that should be done and doing it
fundamentally it doesn't matter
import "a/b/c"
var _ = d.A```
is a valid program provided the files at `/c` have a `package d` declarationas I said, this is obviously something to avoid, but it's important to understand