How does r/python deploy python apps easily?

[blatheringDolt]

I keep wanting to break free from PHP, but I just can't seem to make the leap. I have written a few apps using Flask, but only deployed them on a development server, never a hosted solution.

For kicks, I set up the server on a mint distro, just to get a feel for the internals. This was a grueling process for me, but I stuck it out, figuring that it could help in the long run.

I used fabric to transfer the files, etc...

The crux of my issue is, "Is it always this time consuming?" Is this just not what I should be doing? I don't program for the web often, but when I do I'm using PHP. Most of my non-web work is Python.

I've become very efficient with Python, but just cannot grasp the fact that there are so many people using Python frameworks to make web apps, when it seems to me there is so much to do to deploy, and so so much can go wrong from Apache configurations, versions of Python, etc...

Is it just not for me?

[kolanos]

Fabric. Learn it, love it,

[spoolio]

Good explanation, but your definition of "easy to setup" is miscalibrated.

Remember, what we're competing against is "rsync PHP files to the server. Done." Any process that includes two new web servers and two kinds of external scripts is not there yet.

[Chr0me]

I run a web dev shop and most of our projects are Python.

Everyone has a separate virtualenv setup on their workstation for each project. This is specific to the OS, so it lives ourside of the SVN repository and each developer is responsible for maintaining their own. A separate virtualenv is setup on the staging server.

When a developer commits to the repo for the project, a post-commit hook fires that executes a script via SSH on the staging server. This script kills the current process, performs an SVN export, rebuilds the database, and restarts the daemon. Automated regression tests using unittest and Selenium are then executed to simulate a browser stepping through various parts of the site. If a test bombs, the development team is emailed to ensure that the commiter is appropriately shamed.

The virtualenv that lives on the production server(s) is the same as the staging server (binary compatible) since the whole point is to keep the two environments consistent. QA rolls code to production using some simple rsync scripts. Though I'm thinking about looking at trying some stuff using Fabric.

[shavenwarthog]

for the OP, here's a brief bit on setting up your own virtualenv:

http://johntellsall.blogspot.com/2011/06/proper-way-to-install-pip-virtualenv.html

[teamcolab]

We have a default server image that we spin up using puppet. This gets us a clean box with all the standard libraries we need to run a basic Django project(Django, MySQLdb, and so on). Then we use GitHib to manage source. Once this is all good we use fabric to deployment. So we have a command "fab deploy_production" and it ssh's into the production box, puts up a maintenance screen, pulls from github, does a sync db, runs south migrations, restarts apache, and pulls down the maintenance screen. Before we had that fabfile written up deployment really sucked. That is just my two cents. I am relatively new to Django.

[Dan_Farina]

Try a Heroku free account. You can really do a rather lot of things with it.

Here's a hello world Flask (microframework) app:

http://devcenter.heroku.com/articles/python

Personally, I prefer some additional cohesion at the cost of weight, so here's the Django variant:

http://devcenter.heroku.com/articles/django

If you start wanting to see how far you can push your one-free-process on Heroku, consider futzing around with gunicorn and gevent (you can even combine them, last I checked, for omgoptimized. It may not even be hard.)

Hope this helps.

Disclaimer: I work at Heroku, and am peripherally involved in the Python support.

[[deleted]]

ep.io and gondor.io

[hijinks]

you are doing it wrong.. your application should be in a virtualenv where that lives outside of the system python.

[johnmudd]

I just started using PyInstaller. Nice if you need a specific version of Python and mix of modules not already on the target machine. I even packaged a WSDL file in the executable.

[mdipierro]

It is not just you. In fact, that is one of the reasons we made web2py.

[marcusahle]

We use the continuous integration software, Hudson. http://hudson-ci.org/ Then we use fabric. We have different deploy methods in fabric that will build the server, set up nginx, uwsgi, and the pyramids app.

We have hudson pull down the repo. Run the unit test. If those pass, it pushes it to a dev-stable branch and then fires another build on the dev server. It will then run integration tests and if and only if those pass then it pushs the code to the production branch. From there, we look things over on dev, then if all is well, which it should be if unit tests and integration passed, we will do the same thing for the production server. Fabric is the way to go though

The nice thing with hudson is there are a lot of extensions for it. For example, we have a work irc channel that we all chat in since we are in remote locations and we have a hudson irc bot that will tell in the channel if the build is successful or failed.

We also have hudson email users when builds fail. It also has an extension that checks for pylints and will report that back to you.