I noticed that more and more dns plugins are getting included into the core certbot repo.
That’s will be a problem in the long run IMO. We should move DNS plugins out into their own repos to increase modularity.
At the moment, if I pull the certbot repo into my server to get certificates, I get a whole lot of plugins that I don’t use and they just sit there. If the plugins are moved into their own repos, the size of the core certbot install will go down as well as giving core maintainers less work to do.
The down side will be that DNS plugins will run the risk of going out of date.
As @_az alludes to, the certbot git repository, like many git repositories, is intended for use only by developers, not end users, hence it is organized with developer convenience in mind, not user convenience. As you point out, it’s much easier to test changes when you have all the components in front of you and don’t have to clone ~25 repositories, and much easier to refactor things when you don’t have to open ~25 pull requests.
If you only want a few pieces of the certbot repo, there are many ways to install it piecemeal:
You can use your distribution’s official packages.
You can use blessed third-party repositories like the Certbot PPA for more up-to-date packages.
You can use certbot-auto which doesn’t even include the DNS plugins.
With so many other ways to obtain slimmer versions of certbot, it’s unlikely the developers will be interested in making their life that much harder just to save a few megabytes of hard drive space for people whom the git repository isn’t intended for anyway.
That is true. I prefer to clone the repo to use it. Other people probably only use the packages.
I was more concerned with how there are a dozen dns plugins that are included in the repo. And, more plugins will likely be added over time making the work of maintaining it that much tedious.
In this regard I’d agree with @Patches: we don’t intend for anyone to clone the git repository in order to use Certbot as an end-user. The versions of Certbot that exist in the repository are not considered “released”. In rare cases, they might even be missing functionality that we consider important or have known bugs that are worse in some way than the released versions.
Certbot releases (and packaging) usually involve reasoning and discussion about what functionality should be included and whether anything needs to be modified to integrate with a particular OS—and, at a bare minimum, deciding when enough new functionality has been added to merit a new release.
The git repository exists to promote coordination among people working on developing, debugging, and documenting Certbot, including the Certbot team at EFF and outside contributors. It’s optimized for those purposes, not for other purposes.
As @Patches referred to, we have tests that are run directly by the developers as well as by continuous integration systems that are integrated with the GitHub version of the repository. Some of the CI tests are meant to confirm that changes made to one part of Certbot didn’t harm the functionality of other parts. For most purposes, it’s useful to have as much related code as possible in one place so that the tests that get run in response to every change are as comprehensive as possible.
While a CI system could certainly be set up to test things together that are built from different repositories, I don’t think we’ve seen this as a priority and I think it could make developers’ lives more difficult.