docker-machine-driver-hyperkit: deprecate as it is unmaintained

[andig]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[carlocab]

Thanks @andig. Please use Homebrew/core style when writing your commit messages, like so:

docker-machine-driver-hyperkit: deprecate as it is unmaintained

(or similar)

[alebcay]

Just curious, do you have any information about this being unmaintained?

[andig]

Just curious, do you have any information about this being unmaintained?

I've checked the latest commits, see my comment above. Relying on dep in 2021 is unmaintained imho.

docker-machine-driver-hyperkit: deprecate as it is unmaintained

@carlocab could you change these when squashing the commits this time? Will do in future...

[alebcay]

Relying on dep in 2021 is unmaintained imho.

Thanks, just wanted to understand your rationale. Since it still seems to be getting a lot of use:

==> Analytics
install: 476 (30 days), 1,467 (90 days), 6,824 (365 days)
install-on-request: 469 (30 days), 1,425 (90 days), 6,640 (365 days)
build-error: 0 (30 days)

I do agree that building with dep is pretty annoying.

[andig]

dep is deprecated according to golang/go#38158. I did not analyze if we could provide a non-dep build. If that were possible, it would not require deprecation. If not I'd rather deprecate these than not have go 1.17 ;)

[carlocab]

We should verify first that it is impossible to build this without dep before deprecating it.

[andig]

Only has Gopkg.toml, no go.mod. One can:

• go mod init github.com/machine-drivers/docker-machine-driver-hyperkit
• go mod tidy
• patch the makefile to get rid of the vendor target
• ... and make build

but why should we? It is unmaintained and has already caused pain during the go 1.16 cycle.

[SMillerDev]

but why should we? It is unmaintained and has already caused pain during the go 1.16 cycle.

Because almost 500 people install it every month. Unless there is no way to fix this these people expect Homebrew packages to keep working.

[andig]

Because almost 500 people install it every month. Unless there is no way to fix this these people expect Homebrew packages to keep working.

I fully understand. However, it is an abandoned product. If people keep expecting it to work they will have to face final breakdown sooner or later. You can keep it half-alive by patching everything in Homebrew or fork the repo and adopt the necessary changes at the root.

I'm personally using Homebrew for simplicity of use. My personal preference would be not fixing outdated stuff where it hinders staying up to date with current releases, unless it can be done upstream.

This is of course personal taste. Happy to have this PR closed for a better solution.

[gromgit]

I've pinged upstream to resolve the current situation in an appropriate manner. Let's see what happens.

[SMillerDev]

I fully understand. However, it is an abandoned product.

So we patch it and mark it deprecated, and next Go release we could drop it completely. Since people will have had some warning.

[andig]

Will update with patch