Its really nice to see them bringing in even more flexibility in platforms and environments.

I just hope they had taken a little bit more care in ensuring backward compatibility - both my apps (which I have been running for 7+ months) lost code deployment ability (errors on deploy). The fact that it happened exactly at a time we discovered a major issue in our code base and were stuck without being able to push hot fixes was a major bummer.

Shot off an email to their support 2 hours back - haven't heard back yet.

Fortunately, we sniffed the issue to the new buildpack and found a work around by pointing our apps to use an older buildpack (https://devcenter.heroku.com/articles/buildpacks). While it caused us real heartburn for quite some time, kudos to them for building an infrastructure that is extremely configurable (which enabled the workaround).

Update: Heroku support got back with the same work around. They are debugging the issue with the new buildpack.

We have a similar problem - the upgrade means our slugs have to be recompiled, and heroku's slug compiler times out after 15 minutes. That sounds like a long time, but the development version of gevent can take a good 5-10 minutes to build.

We got an email back from heroku suggesting we push with half the dependencies first, then the other half. Not an ideal solution, as it would take our production app offline.

Cool that its possible to change it, but I don't see any reason to introduce a "runtime.txt" file - seems very random. Would be better with a json file to put in arbitrary settings for the project (I think this is how its done with node.js on heroku, correct me if I'm wrong).

This was very carefully considered. A blog post explaining all of the design decision will be published in the near future.

Essentially, I wanted to use setup.cfg's new 'requires-python' directive. However, distutils2 has been stalled and its future is in question. Distlib was also considered, but it's also quite controversial.

There are some other exciting Python packaging projects being developed actively that seek to solve these problems. We plan to support these standards when the time is right. In the meantime, a simple runtime.txt file suits everyone's needs perfectly.

Could you list out or elaborate on the other packaging projects being developed? I'm very interested in getting involved with Python packaging.

Thanks.

Nothing public at the moment, but you can learn more from Donald Stufft (the guy behind crate.io) https://twitter.com/dstufft

It goes in a JSON file for Node because there's already one present to configure NPM packages, just as for Ruby applications you can define the runtime in your Gemfile. In the Python world their package manger uses a file called something like "packages.txt", and so runtime.txt makes some sense alongside that.

Q: I just wonder when Google App Engine catches up with Python 3. A: Not anytime soon. https://code.google.com/p/googleappengine/issues/detail?id=9...

I love you Heroku.

We love you too :)

Here is the samething for NodeJS - http://news.ycombinator.com/item?id=4957133

Still no websockets :(

Yeah! That's because of their HTTP Proxy. Need official support from Heroku.

What's the history behind the runtime.txt file?

Thank you Heroku for not shoveling this in an xml file

See above comment: http://news.ycombinator.com/item?id=5002564

> By default, we run 64bit CPython 2.7.3

That's cool.

Did bin/post_compile get broken as well? Seems like it isn't running anymore for me.

Got fixed.

Hurrah, progress.

neat ! does django and flask support python 3 too ?

Neither of them support Python 3 but upcoming [1] Django 1.3 will have an experimental support. Luckily you can also other than web stuff on Heroku.

[1] https://www.djangoproject.com/weblog/2012/mar/13/py3k/

I think you mean Django 1.5, Django 1.3 came out a couple of years ago.

I did, thinking of Python 3 messed up my brain.

Django 1.5 should be released any day now, which adds support for Python 3!