I just woke up from my old man nap, so just kick me if I’m spewing fumes. What about having plugins available via something like Webmin and have this automagically parked behind a Basic Authentication wall? And this whole webpanel available as a boolean choice on the initial caddyserver install?
I know. It’s either time to brew a pot of joe or go back to letting the cat sleep on my head.
I’m fine with it if people in the community (you folks) want to package Caddy up for distros. I’m not gonna stop you. 
Do it however you think is best. I don’t have experience in that area. I just ask that if you do so, to keep it maintained and up to date with the latest stable Caddy version.
As an ex-Debian maintainer myself, I think distro packages are a gigantic waste of time.
Developers should use go get. Production users should use Docker.
KISS! 
@matt Why not consider a Caddy-specific package manager that can be installed as a distro package? That way, you’d be able to leave the build process on the Caddy build servers but still automate, say, the creation of a Caddy user/service file/etc. Once we had a functional package manager/build environment, it could even be genericised for other go-based projects.
I think distro packages are a gigantic waste of time.
As someone who doesn’t particularly enjoy writing systemd service files, I think they’re a gigantic time-saver 
Production users should use Docker.
I disagree. Firstly, docker doesn’t solve the issue we’ve run into (distributing a “package” with a user’s selection of plugins), and secondly I honestly don’t think Docker all that good. I don’t want to risk getting too off topic, mind, so I’ll shut up and we can have that conversation elsewhere if you fancy it.
OOOO, cvm = “caddy version manager”
cvm get master
cvm get 0.8
cvm list plugins
cvm install git
Maybe this is what caddyext already is?
That’s an interesting idea. It would require installing Go as well, though. So, not for production use – for development machines only?
Something like that would be good. Not sure if “version” is quite the right word, but definitely something along those lines. I think @abiosoft expressed interest in something like this. We’re going to coordinate so that this tool and the build server can share more of the same code.
@matt My idea is something along the lines of @abiosoft… as an end-user, I install… say, sudo apt-get install cvm, and fire a command, say, sudo cvm install caddy caddy-hugo caddy-git and then cvm grabs the caddy+hugo+git from the Caddy build servers (just like getcaddy already does), drops it in the appropriate location for the distro you’re on, creates the caddy user, setups up the systemd service file, etc, etc.
Basically, I’d like a tool to automate all the things I already do when deploying Caddy for production use 
I think I like what @captncraig just proposed and surely going to put it in consideration. Though I’d go for caddyctl or caddytool over cvm. I am not looking at a version manager, rather a caddy tool.
Erm… cvm is already Caddy version manager, why install Caddy again ?
@abiosoft Yeah, I like caddytool.
Erm… cvm is already Caddy version manager, why install Caddy again?
In my mental picture, the cvm/caddytool/whatever package doesn’t install Caddy itself, it instead grabs the appropriate Caddy binary from the Caddy build servers and plonks it in the right place along with setting up the other guff you need for a decent prod env.
EDIT: Although I would propose calling it something more generic than caddytool, because in that case the Caddy/Caddy plugin architecture could be genericised for other Go-based applications.
Oh no, not another package manager I need to learn to figure out how to install, list, uninstall, rollback, upgrade… please no. 
How, then, do you propose we teach existing ones how to build Caddy with a custom set of plugins?
Can’t we have instructions with go get?
Or have a Dockerfile generator?
But then people need to install Go or Docker (and learn how to use them). I for one would refuse.
You would rather learn a new packaging system for each software you use? 
Golang IIUC is supposed to be all about static binaries. So static binaries can be thought of as packages themselves. If people really don’t want to learn something new, why not create a build service for the crazy permutation explosion of plugins you want to offer users? 
Not really. Caddy is a bit unique though, in that its static binaries are available for every platform right from compilation and don’t need packaging.
Packaging isn’t really the right word here; what we really want is a way for people to manage their Caddy plugins without having to get their hands in the code. Not that it’s bad, but it can be more convenient to just type a command on the command line, and it knows where to get the plugin or how to download a build of Caddy with those exact features from the build server.
So, ultimately all we need to do is wrap the Go tools or the Download page in front of a nice, user-friendly facade that makes it really easy to get a Caddy binary with or without certain plugins.
Or have a Dockerfile generator
No, because Docker is not a solution to this problem.
I was reading about Caddy, and stumbled upon this thread. So just in case you’re still considering package managers, what about trying Packager.io (disclaimer: I’m the guy behind it)?
I suppose it will require a few additional files to have the Heroku Go buildpack correctly detect the app (at the moment it’s failing), but then you would end up with packages for a wide range of Linux distributions.
Let me know if I can be of any help.
I use pkgr (which I believe @cronhr wrote) for packaging our internal applications (and then serve them up using a Ruby on Rails apt-server. It’s awesome.
Maybe this is a problem that doesn’t need a solution (custom plugin selection for packages).
Why not have two packages available: a plain Caddy with no plugins and a Caddy-full with all plugins. I think for most use cases people either want a plain Caddy or will want one or more plugins (but would accept having all of the plugins over none of them). The ability to customise it is cool, and if they want to do that then still having the “standard” getcaddy install method is available - but for people that want to have it easily installed/updated/etc, then having a minimal and full package available for their OS would be fine (probably in 3rd party repositories to allow you to update them frequently).
Anyway, just my 2 pennies worth of internet opinion…
Thanks Yes, I wrote pkgr, and this is what’s used internally by Packager.io.