I apologize. The past couple days have been hectic. First with work, then discovering the need to write a new Sphinx extension to do the best possible job on the overall docs. So, it's been busy and slow (and I'm still working out the basic skeleton for the Sphinx extension, so I'm going to be spending more time on docs than code this release cycle).
On Wed, Jun 22, 2011 at 8:48 AM, Michael Pedersen <[email protected]>wrote: > That one is definitely a long question. In the book that's coming up, > there's at least a couple of chapters devoted to how to distribute/deploy an > application. I'll discuss more later today, but the short answer is this: > You will create either a source distribution or a binary egg (I usually > prefer the source distribution). From there, you may (not required) upload > it to http://pypi.python.org/ . You can build your own eggbasket for > people to install from. You can deploy using mod_wsgi, or nginx, or Paster. > > In other words, you have a lot of options. I'll cover them (at a somewhat > basic level) today, and we'll be putting together proper deployment docs > later. We do have some deployment docs right now, but they are out of date, > and cause frustration for people normally. It's best to ask about them on > the list, and we'll help you through it. > So, how to deploy? This is going to be mostly conceptual, and pointed towards someone who is new to the Python ways. I'll probably be shouted down a bit, but I've found ways that work for me and seem to fit in with what people do/expect for their own distributions, so hopefully it's close to the "right" way. Python code is normally distributed in one of two ways: either as source tarballs or as .egg files. Source tarballs are nicely platform agnostic, while .eggs require all the details to match up for deployment. To create them, you need to know a bit about setuptools, or distutils, or whatever method pip is pushing. You see, Python has gone through one distribution tool entirely, is close to going through a second, and is working on a third. distutils was the first attempt. It worked well enough for most things, but where it failed were on things that mattered to people. Along came setuptools, which addressed many of those shortcomings. It's not perfect, but I get along with it (despite many people hating it). pip is the new "golden child". How long it will remain so is anybody's guess. Binary distributions are fiendishly difficult to get right, and it's true in Python, too. Anyway, for all of these options, the resulting file is usually uploaded to http://pypi.python.org/ for public distribution. On systems with setuptools, you can then run "easy_install package". On system with pip, you can "pip install package". That's the generic stuff. What I've said above is true for any Python application, not just TG. The rest of this is all about TG. When it comes to TG, you need to find a way to deliver your application such that a webserver can hand HTML (and other) files to the users. During your time developing your TG application, you will be using Paster to serve those files. For production, we can't recommend it, though. Paster is slow, and will not scale well for you. For production, we recommend you use Apache (with mod_wsgi) or nginx through one of the WSGI options available there (sorry, I don't know nginx, not yet, but I'll learn it for the book). As a bonus, all of your static files can then be served by Apache/NGINX, considerably improving the performance of your web server (after all, static files getting processed as dynamic can't have a good effect on performance, can it?). However, you simply must not install your program in a .zip file, which is what setuptools (and possibly pip) will try to do. It will break. Preventing the problem is easy: add "zip_safe=False" to your setup.py file (required for building your installation file for PyPI). If you do so, templates will not work, since TG expects to find individual files on disk, and they won't exist (only the .zip file containing them). Now, how to develop your setup.py file and deploy to mod_wsgi? Our docs aren't perfect (in fact, some people very much hate them). However, if you read them knowing that you will need to refer to the mod_wsgi docs, they can make a useful start (that's how I've managed to deploy in the past). For everything else, there's questions. Ask away, we'll answer. -- Michael J. Pedersen My IM IDs: Jabber/[email protected], AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen Twitter: pedersentg -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
