| Message ID | 20210906053607.505949-1-philip@philipmcgrath.com |
|---|---|
| Headers | show |
| Series | Add sendgmail. | expand |
Hi, Philip McGrath <philip@philipmcgrath.com> skribis: > gnu: Add go-cloud-google-com-go-compute-metadata. > gnu: Add go-github-com-google-gmail-oauth2-tools-go-sendgmail. Applied, thanks! Perhaps the 2nd package could be called just “sendgmail” since it provides a CLI? Thanks, Ludo’.
On 9/14/21 5:32 AM, Ludovic Courtès wrote: > Hi, > > Philip McGrath <philip@philipmcgrath.com> skribis: > >> gnu: Add go-cloud-google-com-go-compute-metadata. >> gnu: Add go-github-com-google-gmail-oauth2-tools-go-sendgmail. > > Applied, thanks! > > Perhaps the 2nd package could be called just “sendgmail” since it > provides a CLI? 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. The sengmail utility is recommended in <https://git-send-email.io/#step-2> (by the SourceHut developers). There are some things I don't like about it, but it seems better than other approaches I've tried, like configuring an MTA with (even more) ambient authority. It might also be nice (or it might not) to apply one of the three pull requests since 2019 to support non-"@gmail.com" addresses (e.g. for work or school, from what has variously been known as Google Workspace, G Suite, or Google Apps for Your Domain). Indeed, the upstream repository has not been updated at all since 2019 ... I used <https://github.com/google/gmail-oauth2-tools/pull/37> via a package transformation to submit this patch series, whereupon I discovered I wasn't the first person to have this idea. -Philip
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.
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