Go implementation

[F21]

I am currently working on a Go implementation in my fork and most of the code and tests are done.

The problem I am facing is how the code for each language implementation is generated from a template. For example, in the Go implementation, we would have mail_check.tmpl.go which generated mail_check.go under the platforms/go directory.

The problem with this is that Go automatically looks at all .go files in a directory and considers them to be a package. In this case, attempts to use the Go implementation would fail since it will see 2 sets of the same functions implemented in the package as well as invalid syntax due to the mustache placeholders.

Go does allow the use of build tags such as // +build ignore to ignore a file during the compilation of binaries, but there isn't a way to get this to work because if we include the build tag in the mail_check.tmpl.go file, it will be copied over to the mail_check.go file, which means the library will never build.

I think one solution is to add an exception for Go to generator.js file, but it obviously won't be a very nice solution as we are introducing these exceptions.

[F21]

Another solution would be to rename all the templates to xxxx.tmpl and keep a mapping of the language and file extension in generator.js, so that all generated files in the ruby folder will use the .rb extension, all generated files in the go folder will use the .go extension, etc.

[FGRibreau]

Why not cd into platforms/go in order to only build mail_check.go ?

Or cp mail_check.go into another sub-folder to of platforms/go to do what you want there? :)

[F21]

I am not sure what you mean. Do you mean to perform the cp and cd when compiling the Go implementation in the mailchecker repository?

The problem is that because the template is mail_checker.tmpl.go and the generated file is mail_checker.go. Since they are both in the same folder, they will be picked up by the Go compiler as they have the .go extension. As both files contain struct and function declarations, they are considered to be re-declarations and the build will fail.

[FGRibreau]

Inside a "publish-go" script inside package.json you can there move the generated mail_checker.go into its own temporary directory (in order to follow go conventions) and then do the usual commands to publish the go package :)

    "publish-go": "mv platform/go/mail_checker.go ... && ...",

[F21]

Ah, I see what you mean. The problem is that Go packages are not published to a central repository or anything. Installing the package using go get will clone github.com/FGRibreau/mailchecker directly into the $GOPATH directory on the machine which is then consumed by code importing this repo..

I think it's possible to add a "pseudo" publish-go command to move the generated file to another directory, but the filepath would be very unidiomatic go. The current import path as per #199 is github.com/FGRibreau/mailchecker/platform/go. We could possibly move the final mail_checker.go file into github.com/FGRibreau/mailchecker/platform/go/lib, but it's not very nice and not very go-like.

[FGRibreau]

Why not use a branch instead? Would it work if we had a clean go-branch that was only updated by the « publish-go » script ? Le ven. 11 oct. 2019 à 10:48, Francis Chuang <[email protected]> a écrit :

Ah, I see what you mean. The problem is that Go packages are not published to a central repository or anything. Installing the package using go get will clone github.com/FGRibreau/mailchecker directly into the $GOPATH directory on the machine. I think it's possible to add a "pseudo" publish-go command to move the generated file to another directory, but the filepath would be very unidiomatic go. The current import path as per #199 <#199> is github.com/FGRibreau/mailchecker/platform/go. We could possibly move the final mail_checker.go file into github.com/FGRibreau/mailchecker/platform/go/lib, but it's not very nice and not very go-like. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#198?email_source=notifications&email_token=AABBWQV7VRWMUWBREHKCCPDQOA4XFA5CNFSM4I4IHT3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA7KLFQ#issuecomment-540976534>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBWQQ4FKPRCBNCLPRYWALQOA4XFANCNFSM4I4IHT3A> .

-- Sent from my iPhone

[F21]

Branches are like versions/tags in Go modules. So, if we were to put the generated mail_checker.go file into the go-script, the module system wouldn't work properly. This is because when importing a dependency in go, we can specify a tag using go get github.com/FGRibreau/[email protected] or a branch using go get github.com/FGRibreau/mailchecker@my-branch. If the code is now in a branch, we lose the ability to import different versions or use versioning at all.

[FGRibreau]

Why not create a new branch called « go-vX.X.X » at each release (publish-go)? It will work right? Le dim. 13 oct. 2019 à 05:45, Francis Chuang <[email protected]> a écrit :

Branches are like versions/tags in Go modules. So, if we were to put the generated mail_checker.go file into the go-script, the module system wouldn't work properly. This is because when importing a dependency in go, we can specify a tag using go get ***@***.*** or a branch using go get ***@***.*** If the code is now in a branch, we lose the ability to import different versions or use versioning at all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#198?email_source=notifications&email_token=AABBWQTARAKX7F63FA3TYSDQOKKWJA5CNFSM4I4IHT3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCNU3Y#issuecomment-541383279>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBWQSZO3Y3HBPUATPXQATQOKKWJANCNFSM4I4IHT3A> .

-- Sent from my iPhone

[F21]

That will work, but it won't work well with the go get tool. By default, most people will install the dependency using go get github.com/FGRibreau/mailchecker. This searches for the latest tag and uses that. In addition, there are commands in go get to check whether dependencies are upgradable by minor, patch and major versions. This works using tags in the format vX.Y.Z and will not work with branches. I think using branches to "release" versions would not play well with the go get tool.

[FGRibreau]

@F21 would go.mod be a solution https://github.com/golang/go/wiki/Modules#gomod ?
https://github.com/golang/go/wiki/Modules#how-to-define-a-module

I've never experienced it, but a go.mod in the root folder could do the trick right?

[F21]

There's a go.mod file in the PR, but it's orthogonal to the tagging of releases. The go.mod file is required for modules in go to work properly (most of the time). However, the version selection is done by the go get command itself and it looks up tags rather than branches.

I think the root of the problem is that we have .go files in the same folder declaring the same variables and functions. If the template file does not have the .go extension, it would work correctly.

[FGRibreau]

Ok then, you can submit a PR to both support .tmpl.{languageName} and .tmpl._{languageName} (or equivalent). This should work right? :)

See this line: https://github.com/FGRibreau/mailchecker/blob/master/lib/generator.js#L23

[F21]

That should work 👍 . I'll have a look through the generator code and open a PR for it.

[FGRibreau]

Released in v3.3.0!