[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#50420] [PATCH 0/2] Add sendgmail.
From: |
Sarah Morgensen |
Subject: |
[bug#50420] [PATCH 0/2] Add sendgmail. |
Date: |
Thu, 23 Sep 2021 12:40:24 -0700 |
Hi all,
Leo Famulari <leo@famulari.name> writes:
> On Thu, Sep 23, 2021 at 05:59:44AM -0400, Philip McGrath wrote:
>> That would make sense to me: I'm not sure what the general rule is for
>> breaking out of the language-specific naming conventions, and I'm not a Go
>> programmer, but “go-github-com-google-gmail-oauth2-tools-go-sendgmail”
>> seemed especially egregiously long.
>
> In general, end-user applications (like a CLI program) can use a simple
> name like 'sendgmail', which is what users expect.
>
> Libraries, on the other hand, should use the long name. For Go, this
> should match the "import path" of the program, with slashes changed to
> hyphens, plus a "go-" prefix.
>
> Internally to Go software, the "import path" is the true name of the
> program:
>
> https://golang.org/doc/gopath_code#ImportPaths
>
> For example, there could be multiple Go libraries named 'sendgmail', but
> Go software distinguishes them by including their network location in
> the name.
>
> We could invent another naming system, but Go naming is already so
> complicated that I think it's worth trying to match the internal "import
> path" names.
For what it's worth, I concur, especially since the importer won't see a
package with an "incorrect" name, so we may end up with duplicates.
In the rare case that a module contains both a library and commands, the
command package can inherit from the library package, and set
`#:install-source? #f' (and #:import-path, if necessary).
--
Sarah