[jacques_chester]

> It is widely discouraged

It is also widely encouraged. Some engineers:

1. Don't trust dependencies to always be there.

2. Write apps that need to work in disconnected environments -- ie with no internet connectivity.

I work on the Cloud Foundry buildpacks team for Pivotal. Being able to stage and launch apps in a disconnected environment is A Big Deal for a lot of companies.

[halostatue]

Absolutely. That’s sort of a fundamental reason why I wrote Cartage. I like some of what Capistrano does, but the general insistence on being able to `bundle install` on the target server is questionable, and the earlier practice for Rails apps of keeping the gems in Git resulted in other problems.

Heroku mostly does this right with its 'slug' system, and I made Cartage specifically to be able to make deployable packages that use dependencies. You have a build machine that’s connected to the network and can reach RubyGems (and, in the future with some plug-in work, other packaging systems—I expect to add Node, Elixir, and Lua soon) and that will vendor the resulting build and give you a tarball that is just installable with all of the dependencies of your package.

[jacques_chester]

Cloud Foundry has staging and run steps, much as Heroku does, to the point that a lot of Heroku buildpacks will run without modification ... if you're in a fully connected environment at staging time. It's not an accident: Cloud Foundry was in part consciously inspired by Heroku in the early days, so adopting the buildpacks model was natural.

However, as I noted above, this model breaks for disconnected environments, in which neither the staging container nor the runtime container have internet connectivity.

Heroku's ruby buildpack code runs bundler, Cloud Foundry's buildpack is a soft fork of Heroku's, so either you vendor your dependencies before sending it to Cloud Foundry for staging, or you get a failed staging step when the code in the staging container can't dial out to a remote repo.

[halostatue]

Yeah. That makes sense. My run steps are in Ansible, so it made sense for me to make something that‘s just a packager. The nice thing about Cartage is that it can make use of already-vendored packages (old way) or you can create the deployment package from a developer machine. I really should write it up one of these days, but I’m so busy getting my team’s pipeline fully fed that I haven’t had time to properly shout out about Cartage (because, frankly, it’s kind of awesome if I do say so myself).

[jacques_chester]

Cartage looks neat (thought Googling it took a few tries).

To me it "looks" like a buildpack, insofar as you are taking something, injecting its dependencies and producing an artifact that's ready to run by itself. If you ever whack bin/detect, bin/compile and bin/release onto it, it'll probably work well enough as a buildpack in connected environments.

[halostatue]

Thanks. We’re going to add Node, Lua, and Elixir plug-ins soon to enable standalone running. The nice thing about making just a tarball at the end of the process is that it should be relatively easy to make anything else (Docker image, AMI, etc.) with that.

https://github.com/crohr/pkgr is the only thing that’s nearly similar, and it does a few things differently than Cartage (https://github.com/KineticCafe/cartage for anyone else following this subthread). Pkgr is a little more opinionated on using the OS environment and making sure that OS-level dependencies are fully declared…I leave that to Ansible, for the most part.

[jacques_chester]

If you had an option to package the runtime, you could use the binary buildpack[0] to run Cartage tarballs.

[0] https://github.com/cloudfoundry/binary-buildpack