Lego: Converting project to modules

[vancluever]

Recently, it's been tough in the Terraform ACME provider to maintain properly synced dependencies with lego on part of the project has not converted to modules yet.

This leads to issues at times where the DNS providers will update to a dependency past a version later than is currently specified in our go.mod, which will lead met to having to hunt down the right dependency in the lego Gopkg.lock and fixing the issue manually. This, of course, does not also help when working with dependency issues that don't cause build errors.

I recently tried to convert the project to modules and have the result in https://github.com/vancluever/lego/commit/e633c88103424190b27b8a7c9a1296024d64bbae. The process was actually very painless, only entailing the steps outlined in the commit (init, change the package name from the old location, add one replace line, and run tidy).

There also does not seem to be much in the way of CI tooling that depends on dep, so I don't think anything else needs to be modified. Modules may need to be vendored (and an exported GOFLAGS=-mod=vendor added as well) to help with rate-limiting on CI, however.

If there's no other issues, or any other reason why #706 stalled (aside from the last comment which mentions some issues with auroadns, which I did not run into - it seems that dependency has changed so that's no longer an issue?), can we look into getting this done? I would be able to help make the changes necessary to get it done and put in the PR.

Incidentally, it looks like there's some issues that I need to unpack in Terraform itself before this is 100% fixed, on part to Azure fun, so there's probably not a huge rush on my part as I will probably just continue with what we have kept doing for now.

[mholt]

@ldez If you're OK with us adding a go.mod (and go.sum) to this project, I'd be happy to do the code review, etc. Just let me know!

[ldez]

If we want to create a go module and respect module rules, as lego is in v2, the go module must be:

module github.com/go-acme/lego/v2

And imports must be updated to github.com/go-acme/lego/v2, but it's a breaking change.

So I planned to break the CLI and some others things and create a v3 with the correct module path.

I'm working on that seems several months but I need time.
Sorry not to be fast enough on the subject, I do my best.

[mholt]

And imports must be updated to github.com/go-acme/lego/v2, but it's a breaking change.

I wouldn't say it's a breaking change. No one _has_ to change their imports, unless they are already supporting modules in which case the version is pinned at a non-breaking commit anyway.

The Go wiki does recommend bumping the major version anyway, though, as a signal to downstream users: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

I just went through this with Caddy so I now have a bit of experience with this. (The reason it was difficult with Caddy is because of the build server, plugins, a repo move, etc, etc, none of which apply to lego.)

I say we go for it. Let's make a v3 branch, tag v3.0.0 with a go.mod, and then whatever other breaking changes you have planned can go in the v4 tree.

[ldez]

When I say it's breaking, I'm thinking about that:

Pre-existing dependency management solutions such as dep currently can have problems consuming a v2+ module created in this way.

FYI a complete migration looks like https://github.com/go-acme/lego/compare/master...ldez:feature/migrate-gomod

[mholt]

Ah, okay. Would you be alright if we did that sooner rather than later, as a v3? Then future breaking changes can be v4, etc. (We might as well just get it over with, I think.)

[ldez]

Let's go :tada: #943

[mholt]

Wooo! Awesome, thanks for working on this @ldez!

[vancluever]

Thanks to both of you!!! 🙂 ❤️