Compound Thinking

TG1.x Gets CherryPy 3 compatibility

Looks like the TG 1.x team has been doing good things. CherryPy 3 is support is a very, very good to hear that it’s been integrated into TG1, because this sets the stage for a much longer support cycle for TG1.

CherryPy 3 is a more solid base to work with, and it’s easier to invision supporting it for several years than it was with CherryPy 2.x. And the test-refactoring work that has gone into making this happen is a huge benefit as well, because you will be able to write application level tests that work in tg 1.5 and will still work in 2.0, easing that migration path.

Florent Aide may be on vacation, but things are still moving forward very quickly on the 1.5 front. I’m looking forward to seeing a release with all this great stuff in it.

Sphinx and TG2 docs

We’re hard at work trying to make the TurboGears 2 docs into something best in class. There’s a long way to go, but the toolchain we’re using keeps getting better and better thanks to Sphinx and Bruno José de Moraes Melo and his GSoC work.

Sphinx all by itself provides a great system for turning ReStructured Text (ReST) files into usable documentation. Since the TG docs were in MoinMoin already, and we’d been careful to use ReST, getting started with sphinx was pretty easy. We updated the doc strings in TG2 to take advantage of the sphinx autodoc features to do API level documentiaton.

But the missing piece was pulling example code in from working sample projects. Sphinx had some include helpers, but they weren’t flexible enough for our needs. So, Bruno has created a set of sphinx extensions to help us. The first of these imports working files from projects checked into subversion. This allows us to show progressive enhancement of projects, and it allows us to keep the working example code under the same source control system as the docs.

So now our Wiki20 source doc has sections that look like this:

.. code:: Wiki-20/wiki20/controllers/root.py
   :revision: 4831

Thanks to the sphinx goodness the code this pulls in is going to be color coded for automatically. Bruno has also added the ability to mark of specific snipits of source code so that you can import just the bit you want to show off like this:

.. code:: Wiki-20/wiki20/templates/page.html
    :revision: 4831
    :section: PageName

and where the PageName section is marked off like this:

<!-- ##{PageName} -->
    Page Name Goes Here
<!-- ## -->

Bruno is working on a few more extensions to sphinx, that automatically test project code before adding it to the doc, and that automatically zip up the sample project and make it available so that documentation uses can easily download it.

I’m pretty excited about how the docs are shaping up, and I’m hoping that a few more people get involved in writing good docs, because the TG team is very much committed to trying to have the best possible docs. Docs aren’t sexy, but good docs can make or break a the use of a framework for new users getting started, and advanced students who are trying to do complex things.

Retirement is a dangerous myth

I’m convinced that the retirement myth is one of the ways we get conned into working too much now.

I’m not against work, but I’ve seen enough burnout to say that too much work is definitely bad.

If you come to the realization that work in itself isn’t evil, you can stop living your life as a waterfall-planned software project too. No need to divide your timeline on earth into the false dichotomies of Sucky Work Era and Blissful Retirement Era. Instead, you can just fill your life with a balanced mix of activities that you can sustain for decades.

– David Heinemeier Hansson

I have a book on personal finance, which defines work as the process of trading your life for money. Overall I think it’s a good book. And I think that it makes a good point, which is that you are trading your life for money, so whenever you buy stuff you don’t need, you’re paying for that with a piece of your life that you can’t ever get back.

But I think work can be interesting, engaging, and ultimately meaningful. So, I’m glad that I have a job that lets me trade my time for money, intellectual challenge, and meaning. And I’m working to achieve financial independence, not so that I can quit working, but so that I can do more meaningful work.

I also think Dave is right to suggest that you shouldn’t be waiting until requirement for life to get good. I also recently read The Four Hour Work Week, and while I’m not sold on every idea in the book, I do think mini-retirements make good sense in a world where I could easily live to be 100, or I could die next week. I think it’s important to make a good life now, taking time out from work to relax, because I might very well need to keep working even into my 90′s.

Unfortunately, all of this is very hard for me to put into practice. I work too much, and I dance on the knife-edge of burnout all the time. But I’m making progress. I work less now than I did 4 months ago, and I’m more engaged in the work that I’m doing, and that has made a huge difference in quality of life.

It’s been a couple of years since I left a company that was sold on the 60+ hour work week, and where I definitely danced right on over the burnout line, and I’m committed to not going back.

Not even if you wave the carrot of “early retirement” in front of me.

Setuptools, Package indexes, and releases

I’ve been doing package management related stuff a lot recently, and thanks to a nice little script Chris McDonough showed me, it’s easy to turn a directory full of eggs into a PyPI (Python Package Index) style index page.

And now I’m pretty much sold on the the idea of having separate indexes for all our major releases so that there’s a known, tested, set of versions and dependencies, that can be easy_installed with one command to get a working install. When combined with Ian Bicking’s virtualenv package, this pretty much solves the package management problem for users, because they can keep a lightweight virtual environment for each version of the software they want to have, and because they can have a reliable and repeatable way to get a specific version of TurboGears along with all of it’s dependencies.

For projects like TurboGears, Pylons, or Zope, where there’s a pretty large set of dependencies it makes good sense for the development team to take on the burden of managing packages and versions for users. This is of course conceptually similar to creating a Linux distribution, but fortunately it’s orders of magnitude easier. We have around 40 packages in the turbogears 2 index, but Ubuntu has well over 10,000 packages. And in a world of interconnected componets one of the core value-adding propositions that a “megaframework” adds is the ability to get a pre-vetted set of packages that are known to work together.

And it’s in that light that I’m thinking about a time based release schedule makes sense. It’s not so much that we need to change the core TG2 code all that often, but there are lots of components and interactions, and it seems like there’s a value in providing regular “distributions” where we’ve tested everything and proved that it all works together well.

TG2 Plans

I don’t have lots of definitive plans, but I expect that we’ll have a new TG2 release next Monday (the 14th.) And that we’ll have another preview a couple of weeks after that.

There are some tickets and milestones in the turbogears trac instance.

Preview 2 details

Some tickets will probably be added between now and Friday, when I intend to finish up whatever’s planned for Monday’s release. And the Preview-3 milestone is still very much in flux.

Preview 3 details

I’d love to see some work done on improving mime-type support, improving support for RESTful resources, and some further definition of what TurboGears 2 site components are going to look like.

How you can help:

If there’s something that you really want in a particular release, feel free to add a ticket (due to the very high volume of trac spam we’ve been receiving you do need to create an account before Trac will let you add a ticket!).

And if you’re up to it we always love patches attached to those tickets! :)

And of course if you’re up for working on existing tickets, we’ll be able to get more done more quickly and get 2.0 final out the door sooner.