Imports & Dependencies about lego HOT 8 CLOSED

Yes... I also do not feel too good with all these dependencies directly in the acme package.

My thought was that I first wanted to get the feature stable and then do a clean up to structure it in a way I feel comfortable with.

As we progress on DNS-01 I think it is a good time to start thinking about this.

from lego.

That being said... I am in favor of packages per DNS provider and just having the manual provider in the acme package itself as it does not add a dependency but allows for completion of the challenge.

from lego.

I actually got an email from someone packaging Caddy for Debian and since Caddy uses the acme package, and mitchellh/goamz was one of them that was questioned as why it was being used. Also the miekg/dns package is cool but it's huuuge.

+1 to refactoring.

from lego.

related to dependencies, was there a specific motivation for using mitchellh/goamz over https://github.com/aws/aws-sdk-go?

from lego.

ping @janeczku

from lego.

+1 to the refactoring

related to dependencies, was there a specific motivation for using mitchellh/goamz over https://github.com/aws/aws-sdk-go?

Mostly that it seemed overkill to import such a huge library for basically just a single API method:

from lego.

@jehiah #144 was merged and it removed most of the dependencies from the ACME package.
The dependency tree looks like this now:

github.com/miekg/dns
github.com/square/go-jose
github.com/square/go-jose/cipher
golang.org/x/crypto/ocsp
golang.org/x/net/publicsuffix

We could not get rid of the github.com/miekg/dns dependency for the time being as it is needed to do the DNS checks for the validation records and I was unable to find a proper solution to move this check out of the challenge itself.

from lego.

@xenolf this is fantastic. I think that resolves this issue!

from lego.