@joe I can understand the sentiment, but I think the issue is that we’re simply at the stage where no tool is refined enough to solve everyone’s problem elegantly, so many different tools are being created; the resulting competition should produce a natural form of selection which will push the best tools to the top, eventually narrowing us down to just a few solid tools which solve the problem for two different classes of developers/teams, small-medium and large. It’s just too early to expect one tool to dominate and also solve everyone’s problems. I’m of the opinion that we’re unlikely to ever have one tool which works for everyone, but I do hope that we can narrow it down to just a few solid choices. It’s not impossible we could get to one tool, but it remains to be seen how things will shake out.

1. They try to do the same thing, but all in different ways. Right now, my personal opinion is that bootleg has the best foundation, but I recall thinking similarly about gatling prior to bootleg showing up, so competition will need to sort them out. Edeliver seems to work for plenty of people, but I have also seen many issues raised on the Distillery tracker which seem to arise from it, so that has tainted my opinion a bit. It is also a very complex shell-based tool, which will be difficult to maintain, I think a primarily Elixir-based tool, with the bare minimum of shell required, is likely to be a better foundation to build on. That said, I very much want to be clear that Edeliver was the first tool which actually did a good job of automating build/deployment in Elixir for those not already using some kind of CI/CD pipeline, and I think the team deserves a lot of credit for that, and certainly some slack.
2. I’m not sure if you maintain any open source projects yourself, but speaking from experience, if it’s just one or two devs maintaining a project, it can be extremely difficult to keep up with the volume of issues and PRs. In many cases, issues are poorly contextualized or described, information needs to be pulled from the person filing it, PRs are messy or poorly explained, or even just plain broken or buggy. That screenshot is a far cry from terrible. Issues or PRs with no comments of any kind is a bummer, but having been a solo maintainer of both exrm and distillery, I can relate to finding it difficult to make time when you have to do it all in your spare time. I always make the attempt to at least leave some initial comments, but I have certainly left issues lingering for long periods of time if they are low priority. Highlighting that the last commit was 28 days ago doesn’t tell us anything either, because there could be work occurring on local branches which hasn’t been upstreamed, and won’t be visible. Try to judge based on the merits of the project, and don’t forget many of these projects are things one or two people are maintaining in their spare time at home
3. I agree that tooling needs to support simpler use cases, requiring a complex build setup isn’t practical for individual developers deploying stuff to Digital Ocean or something. That said, I think it’s not unreasonable for a tool to expect that the majority of teams will have this kind of pipeline, and optimize for it. I think most tools should try to provide a path for using a local Vagrant or Docker instance to act as the build/staging servers, expecting developers to be willing to install one of those seems like a fair expectation. One already has the basics needed via Distillery to stick to the simplest tools, e.g., rsync or scp + a simple shell script to automate the deployment if they are not willing to get their hands dirty to set up a basic build/deployment pipeline. The maintainers of such tools have to set some boundaries though, at least until they get enough contributors to support different use cases, otherwise it slows development to a crawl due to fear of breaking support for some cases they don’t use themselves.
4. The “best” way of getting environment variables into your app is entirely based on your environment. That could be using REPLACE_OS_VARS=true with Distillery using strings like "${SOME_VAR}" in your config file, then extract and parse the value using Application.get_env/3 plus whatever code to post-process the value. You can also skip the first part, and just use System.get_env/1 for simple cases. If you need to configure dependencies via environment variables, then you will need to reach for a tool like Conform or something else, which can handle performing configuration prior to boot. This could even be implemented yourself as a script of some kind which is run in a pre_configure hook with Distillery. The bottom line is that it depends what kind of configuration you need to do, and what you need to configure. Phoenix 1.3 is taking the approach which is now generally recommended for libraries, which is providing an init callback which allows you to configure the application before it starts, in whatever way works best for you. Since that is a relatively new approach, there are plenty of libraries which don’t support this, but that will change. For dependencies which you need to configure before boot, but don’t provide some other mechanism, you can use included_applications, adding their top-level supervisor to your application’s supervisor, and configuring them in your application’s start/2 callback; this is not ideal, but allows you to perform the configuration step in Elixir, using whatever approach you want or need.

I appreciate the kind words about Distillery . Since we’re on the topic, the reason I never tried to solve the problem these other tools are solving, is that I wanted to keep Distillery focused on being a solid foundational layer, so that it’s malleable enough to fit any use case, and let other tools build on it. Also, I’m just one guy, so I probably would fail miserably at maintaining all of that on my own

I enjoyed this talk at EmpEx about edeliver https://www.youtube.com/watch?v=H686MDn4Lo8

Distillery vs. Exrm vs. Relx