search

mcollina / heroku-buildpack-graphicsmagick

67 stars 77 forks source link

Use versions to determine stack #15

Closed RobbinHabermehl closed 8 years ago

RobbinHabermehl commented 9 years ago

As "cedar" is getting replaced by "cedar-14" most people will be interested in using this buildpack for "cedar-14". Unfortunately, regardless of your stack, the Vagrant configuration creates two VM's.

Considering the fact that heroku-buildpack-multi supports versioning I'd like to suggest the following; limit the Vagrant configuration and scripts to "cedar" and tag this as v1.0.0, then change the configuration for "cedar-14" and tag this as "v2.0.0".

This way the buildpack automatically uses the latest version, and users of the "cedar" stack simply suffix the URL with #v1.0.0. When building your release it works the same way, by default it's configured for "cedar-14" usage. For the "cedar" stack you can just check out the "v1.0.0" version.

benalavi commented 9 years ago

@RobbinHabermehl I'm not sure I understand the problem.

Heroku should automatically use the correct binaries based on the STACK environment variable when building the environment, so for anyone just using the buildpack on Heroku it should just work regardless of which stack they are using (unless of course there is a bug, but that is the intention).

The Vagrantfile is just used to bring up VMs to build your own binaries, but I'm not sure what the issue is with bringing up two VMs. The way this is intended to work we can independently fix issues w/ each stack w/o keeping track of multiple versions.

Perhaps I am misunderstanding the problem here though?

RobbinHabermehl commented 9 years ago

No, the buildpack itself on Heroku works just fine. My issue regards the custom builds using the support/package_graphicsmagick script on Vagrant.

When launching Vagrant two VM's are installed and launched, while most developers don't necessarily want to build GraphicsMagick for both stacks. Actually, I think most developers just want to build one stack and therefore I created this issue. I suggested a version-based delegation to reduce installation, launching and building overhead. Especially the installation takes a very long time in my experience as the download speed of the Vagrant box and the updates of its components isn't very good, and right now this has to be done twice!

In short; reduce the Vagrant file to the "cedar-14" replication and tag it "v1.0.0", and then adjust the Vagrant file to replicate the "cedar" stack only and tag it "v2.0.0". Then a developer that wants to build for "cedar-14" can check out v1.0.0 and a developer that wants to build for "cedar" can check out v2.0.0.

EDIT: In case you don't want to mark the "cedar-14" part as legacy code by versioning it, another option would be to create two separate Vagrant files; one for the "cedar" stack and one for "cedar-14".

benalavi commented 8 years ago

Dropped support for cedar entirely as heroku phased it out Nov 4th, 2015