The vulcan node build server seems to have a handful of dependencies that aren't public (unless I'm missing something? - e.g. logger, spawner, cloudant): https://github.com/heroku/vulcan/blob/master/server/web.coff...
The vulcan node build server seems to have a handful of dependencies that aren't public (unless I'm missing something? - e.g. logger, spawner, cloudant): https://github.com/heroku/vulcan/blob/master/server/web.coff...
The logger, spawner and cloudant coffeescript files are in the lib folder: https://github.com/heroku/vulcan/tree/master/server/lib When the app is created it sets NODE_PATH=lib so the app can find those files without specifying the full path: https://github.com/heroku/vulcan/blob/master/lib/vulcan/cli....
slugfest, thank you for the detailed response. By "this route" I just ment creating independent isolated environments for the various runtime to operate within. Based on comments made on the GAE mailing list, I suspect they have moved in this direction. After reading your post I now understand that the issue is not allowing indiscriminate code to work in isolation, but to allow that code to interact with external ser…
App Engine just isn't intended or designed for that kind of interaction with services. Take memcache as an example. On a VPS, you install an OS package and manage memcached as any daemon. You are editing the configs and compiling your own binaries if you want. Set it up on a separate box if you want. Set up a bunch of memcached boxes if you want. Do the wiring how you want. It's up to you and you handle all the detai…
Thanks again slurgfest. I appreciate the way that App Engine does thing. What I ment to say, sorry it wasn't clear, is that by exposing a generic api to various services memcache, datastore, etc. App Engine could make it easier to add additional runtimes. And now that I think about it - I'm sure they are doing this to an extent.
what are the differences/advantages/drawbacks between a buildpack and an automated deploy script that installs OS packages? What happens in an environment where you have multiple applications with different but overlapping dependencies?
My guess is that it depends on the buildpack. The Python one wraps everything nicely in a virtual environment.
If my information is correct Heroku is using Linux containers to keep everything nice and sperate.
ActiveState's Stackato private PaaS platform ( http://www.activestate.com/stackato ) has support for Heroku buildpacks to deploy ( http://docs.stackato.com/deploy/buildpack.html ), as well as the usual options for polyglot app deployments (it also has a 100% compatible Cloud Foundry API). This is useful when you want portability (deploy on a PaaS that you have full control over).
Stackato rocks!
I really wish they would publish some prices though. I'm hesitant of the "contact us" pricing model.
App Engine just isn't intended or designed for that kind of interaction with services. Take memcache as an example. On a VPS, you install an OS package and manage memcached as any daemon. You are editing the configs and compiling your own binaries if you want. Set it up on a separate box if you want. Set up a bunch of memcached boxes if you want. Do the wiring how you want. It's up to you and you handle all the detai…
Thanks again slurgfest. I appreciate the way that App Engine does thing. What I ment to say, sorry it wasn't clear, is that by exposing a generic api to various services memcache, datastore, etc. App Engine could make it easier to add additional runtimes. And now that I think about it - I'm sure they are doing this to an extent.
Sorry that I keep running off in the wrong direction.
They control the runtime in a very heavy-handed, opaque way to lock it down and I doubt that would ever change. New runtimes will be 100% up to Google to implement and they seem not to be a high priority in general - Java seems to be favored for the enterprise people and Go and Python have had involvement from the respective language creators... Google has only so many major language creators ;)
Just part of how App Engine is a closed platform really (although it's not like all of Heroku is open either)
Oh, Heroku, how can you have such an excellent build system and yet you can't support WebSockets? You've spoiled me, and it's so painful to have to use other services now just because you think the standard is too much in flux.
I'd like to point out a Common Lisp buildpack. I've used a fork of it and it's pretty spiffy. (Now if I only knew a simple app I could give people. :-) ) https://github.com/mtravers/heroku-buildpack-cl
That's awesome - thanks for pointing it out. I've only poked around Heroku a bit with basic applications and the standard stacks (Python w/ Flask, etc.), but I think I'll look into what would be required to create a buildpack for Racket. That is, if someone hasn't already beaten me to it... EDIT: As figures, it already exists[1]; I'll toy around with it and test it out before suggesting they add it to the list. https…
Hi.
OpenShift is also interesting.
And if you need something to hack on, see