[NEW PORT] mail/mailhog: MailHog development mail server

[ultima]

Summary

MailHog is an email testing tool for developers:

Configure your application to use MailHog for SMTP delivery
View messages in the web UI, or retrieve them with the JSON API
Optionally release messages to real SMTP servers for delivery

WWW: https://github.com/mailhog/MailHog

PR\: 221015
Submitted by\: punkt.de Hosting Team (maintainer)
Reviewed by\: lifanov (mentor), matthew (mentor)
Approved by\: lifanov (mentor), matthew (mentor)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

Test Plan

portlint:
looks fine.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

[ultima]

• Removed name from comment.

[mat]

mail/mailhog/Makefile

8 ↗

(On Diff #32190)

The distname does not seem to contain a version, so a new version of the port will create all kind of checksums errors. You must use DIST_SUBDIR here.

DIST_SUBDIR= ${PKGNAME}

22–24 ↗

(On Diff #32190)

It is usually better, and way, way easier to understand, to simply write a do-extract target, something like:

do-extract:
    ${CP} ${_DISTDIR}/${DISTNAME} ${WRKSRC}

[ultima]

• Fixed noted items

[ultima]

mail/mailhog/Makefile

8 ↗

(On Diff #32190)

Yeah, I should have seen this.

[matthew]

Hmmm... this is downloading a pre-compiled executable. While that's not unprecedented in the ports,
it is usually desirable to download and compile source code. Certainly applications written in go in
the ports should be compiled unless there is very good reason not to.

[ultima]

In D12069#250581, @matthew wrote:

Hmmm... this is downloading a pre-compiled executable. While that's not unprecedented in the ports,
it is usually desirable to download and compile source code. Certainly applications written in go in
the ports should be compiled unless there is very good reason not to.

Yeah I mention to the maintainer that compiling source is preferred. This was the response:

So you'd rather add a dependency on Go than use the provided binary? I wouldn't ...
I currently don't have the time to completely refactor this port to compile from sources. We use mailhog throughout the company for development, it is a great tool, and we create local ports and build packages in poudriere whenever possible.
I just wanted to share ...
Does the port as it stands have a chance to get committed or is installing the binaries a no-go? I would definitely improve the rc script in the next couple of days as requested.

I'm not really too familiar with go, touched upon it a couple times. Could make it my next todo if you would like? It would be good to learn.

[matthew]

In D12069#250612, @ultima wrote:

In D12069#250581, @matthew wrote:

Hmmm... this is downloading a pre-compiled executable. While that's not unprecedented in the ports,
it is usually desirable to download and compile source code. Certainly applications written in go in
the ports should be compiled unless there is very good reason not to.

Yeah I mention to the maintainer that compiling source is preferred. This was the response:

So you'd rather add a dependency on Go than use the provided binary? I wouldn't ...
I currently don't have the time to completely refactor this port to compile from sources. We use mailhog throughout the company for development, it is a great tool, and we create local ports and build packages in poudriere whenever possible.
I just wanted to share ...
Does the port as it stands have a chance to get committed or is installing the binaries a no-go? I would definitely improve the rc script in the next couple of days as requested.

I'm not really too familiar with go, touched upon it a couple times. Could make it my next todo if you would like? It would be good to learn.

Dependencies are not something we have much concern about: that's pretty much what the ports exists to deal with. There are plenty of programs written
in go in the ports already -- the biggest problem with them is that they tend to require specific versions of go libraries integrated into their sources,
which leads to a lot of duplication, something packaging systems try and avoid.

From looking at their github account, the biggest wrinkle here is that there are a dozen or so sub-projects, which would all need to be unpacked into ${WRKDIR}
rather than the more usual arrangement of subdirectories within the main source tree. That's all do-able. By all means do have a go at writing a port to
compile this. There's quite a few go ports already in the tree that you can use for inspiration.

[ultima]

• Reworked port to compile from source instead of using pre-compiled package

[matthew]

That didn't seem too hard now.

mail/mailhog/Makefile

15 ↗

(On Diff #32262)

Do you know if this is still valid? Now you're compiling from source,
in principle it should work on any architecture there's a toolchain for.

[ultima]

mail/mailhog/Makefile

15 ↗

(On Diff #32262)

I'm not sure, this was only added before because these were the architectures prebuilt. Will remove it because the other architectures are tier 2+ anyway and there is a chance it may run on them.

[ultima]

In D12069#250722, @matthew wrote:

That didn't seem too hard now.

Yeah, it was a little difficult at first understanding the importance of directory structure and finding the proper solution and... I just noticed I committed the tags file, I'm going to have to change the stored directory for this.

[ultima]

• Changed stored location of tags file, removed tags file.

[matthew]

[mat]

head/mail/mailhog/Makefile

41 ↗

(On Diff #32270)

This is wrong. You must set GH_PROJECT=Mailhog instead.