Remi and Sylvain have created The CherryPy Documentation Project, which uses a new blog-like program to maintain their docs. Docs for open source projects often lag behind the project by quite a bit, and it’s good to see that they’re going after that problem head-on.
I think I’ve blogged about these before, but there are some that I don’t remember seeing previously. These things are just too cool to ignore: Julian Beever’s pavement drawings.
At long last, the primary TurboGears mailing list has split. This list has 1,400 members and a lot of traffic. Given that 0.9 is now out in alpha, I thought it important to separate the discussion of current and minor release topics from the stuff that’s a little ways out. The TurboGears Trunk mailing list is the one for this purpose.
I opted for “trunk” rather than “devel” because everyone who uses TurboGears is a developer and I’ve seen many cases of people posting to the wrong list because the dividing line is hard to spot sometimes. So, the trunk list is for people to discuss stuff that only appears on the trunk.
In other mailing list news, Spanish speakers now have an outlet with the turbogears-es mailing list. In Alberto’s words:
Sé de buena tinta que por aquí ronda más de algún
hispanoparlante… Hemos decidido abrir una nueva lista sobre Turbogears en Castellano para todo aquél que esté interesado en aprender acerca de este nuevo framework pero esté encontrando dificultades por el idiomaTodo el mundo está invitado, la lista la teneís aquí:
http://groups.google.com/group/turbogears-es
Estaría bien establecer algún puente para intentar traer a la “oficial” cualquier cosa interesante que se comente por ahí. Por ahora me ofrezco yo
Christian Wyglendowski posts a great summary of where CherryPy 2.2 stands with regards to WSGI. If you’ve followed the discussion on the various mailing lists and thought CherryPy only minimally handled WSGI, this post does a great job of setting the record straight. CP2.2’s WSGI support is not 100% ideal, but it’s way better than 2.1 and you can do an awful lot with it. Big kudos to Christian, Robert Brewer, Ian Bicking and Phillip Eby for hashing it out and coming up with an implementation that meets CherryPy’s backwards compatibility needs and takes a big step forward.
As Ian mentioned in his PyCon 2006 wrapup, we ran an experiment during the TurboGears sprint to see what TurboGears looks like built entirely on a WSGI stack. It actually looks pretty cool. There are lots of nifty application composition possibilities and quite a number of ways to share code with other projects. Something I wasn’t aware of heading in to PyCon was Christian’s filter that allows you to attach other WSGI apps to your CherryPy object tree. With that capability, it should become possible to do everything that we could do with our experimental branch using CherryPy 2.2.
This leads to really interesting questions on how to proceed with the post 1.0 TurboGears release that will have these features. (This fabulous release is code named “First Class” and appears in a branch called firstclass in the repository.) There are always tradeoffs. The one thing is certain: First Class uses WSGI in a big way, and I’m really looking forward to the possibilties.
Discussion of First Class will take place on the new turbogears-trunk mailing list that will be used for discussing unreleased code.
cmd.exe on Windows sucks. Cygwin and MinGW aren’t really Windows (though they are certainly better and cygwin is what I use). So, I ask the lazyweb: is there a better command line for Windows? It looks like the company that made 4DOS (JPSoft) is still around and makes better command lines. They’re not entirely cheap though. Are there any free choices?
Seems like this would be a good Python project, given the tools for making Python command prompts and the excellent Windows integration that’s available.
Despite being a Python user on and off for a decade, this year’s PyCon in Dallas was my first. I doubt it will be my last! I had a great time. There were quite a few interesting talks. Hearing about Python 2.5 in detail from the source was good. As someone heavily involved in Python web development, the Plone, Zope and Django talks were interesting and educational.
To see some of what you missed, check out the PyCon 2006 photos at Flickr. My talk seemed generally well-received and I enjoyed giving it. It’s amazing how quickly 25 minutes can zoom by!
The highlight of the conference for me was definitely the interaction with so many smart Python programmers. I saw many names that I’ve pop up over the years in Pythonland, and had a good chance to talk with a few.
There were so many great conversations in the hallways, the lobby, the bar and the nearby restaurants that it’s hard to imagine not being pleased with the overall experience. Python has a great ecosystem of all kinds of people doing interesting work. On Saturday night, a bunch of folks involved in Python web development got together:
The only problem with this dinner was that we only played musical chairs once. While I’m sure the serving staff appreciated that, it meant that I didn’t get a chance to talk with most of the folks in the picture at left above.
TurboGears sprinter Mike Orr wrote a good overview of the conference: PyCon 2006 Dallas LG #124.
If you use Python seriously, it’s really worth the trip (see you in Dallas next year!).
The TurboGears sprint that followed the main conference was fun and interesting. We specifically went after bigger things that needed kickstarting and would benefit from being face-to-face with other people. One example is the Docudo project: a tool to handle software documentation in a way that works a lot better than a normal wiki. The Docudo team (Joel Pearson, Karl Guertin, Mike Orr, Arthur McLean, and Kevin Horn) started the project from square zero and will have the project eating its own dogfood before we know it.
David Stanek and Mike Pirnat were running tests and experimenting with Kid’s internals with an eye toward making it faster and simpler. They made progress on both of those counts, but it’s not quite done.
I worked with Ian Bicking, Matt Good, Gary Godfrey and Bill Zingler on improving TurboGears’ WSGI support. We created a branch with the goal of really ripping things up to see how far it could go (the answer is: a very long way). On the tgpycon branch, it’s possible to do all kinds of neat tricks with application composition. This work will also make it possible to integrate and share code with other frameworks in many more ways than we can do at present. I’m really excited about this branch, and I’m looking forward to the day when it gets promoted to the trunk.
We could have spent our sprinting time knocking off tons of little items in TurboGears. The path we took worked out better, I think. It’s easy to tackle those little items individually as we do our other work. The stuff we did at PyCon will ultimately have a big effect on the project. Thanks to everyone who participated!
Last week, it was a Python template engine. This week, it’s JavaScript tabs library. It seems to be a fairly common occurrence that people release developer-oriented open source packages that come with a GPL license. Unless you intend to create a business selling your software with a different license to business (the Sleepycat model), this just seems like a way to severely restrict use of your library. The only people likely to use libraries like those that are licensed under the GPL license are people that are writing open source (GPL) applications. If that’s what you want, fine… but, I think it’s better to aim higher. (In case you read no further, those two packages have since relicensed under MIT style licenses.)
I understand the allure of the GPL. “I’ve put this thing out there for free, and so I should benefit from the changes other people made!” (I’m ignoring the “software should be free” philosophical argument for now.) I think it’s a mistake to think that just because something is released under a liberal license, like the MIT license which is what I use, that companies won’t contribute their changes back to the project.
Creating a fork of a project is a pain. You have to reintegrate changes every time there are improvements in the core project that you want to take. For a company to maintain their own internal version of your project effectively means that they have their own fork of it. That just doesn’t make good business sense. A company could choose to take your project and produce some spiffy commercial version. Odds are, though, that they’d still release changes to the core system back to the project, rather than maintaining a private fork.
I think that most people who choose the GPL for a library do so because it’s a license they’re familiar with. That’s the point of this post: hopefully, more people creating libraries will recognize that a very liberal license like MIT or BSD is the way to win users. The authors of both of the projects that I mention above have agreed to relicense under MIT-style licenses!
I should also point out that the LGPL is somewhat ambiguous when it comes to dynamic languages. If you really want a license that requires the open source release of changes on a library that you’re releasing, you should think about the Mozilla Public License. (Update: The CDDL appears to be a version of the MPL that is designed to be more easily reused. That’s a good one to consider.) That license is not vague: only the files in your distribution are required to remain under the MPL. So, the code is free to use for commercial purposes, but any changes to the files that you distributed also need to be released under the MPL. I’d still recommend going with an MIT license in general, but at least the MPL is clear in its effects.
By the way, I have no problem with using the GPL for applications. Applications released under the GPL can be used for all kinds of purposes, and it’s reasonable to want changes to the application to be similarly licensed.
Update: I eliminated the use of the word “viral” above, because I didn’t intend to make a negative point on the use of licenses that impose restrictions on distributed versions of software. My point is that many choose these licenses without being fully aware of the ramifications.
It is also clear from the comments that I never got back to the “software should be Free” (software libre) argument.
As mentioned in the comments, not everyone is looking for the broadest possible adoption of their code. Some people specifically have the belief that all software should be free to use, upgrade and share. People are certainly free to have and exercise that belief by licensing their software under the GPL. If I asked someone to relicense and they told me that they chose GPL to ensure freedom of the software, I wouldn’t argue any further. Those people have chosen the GPL for the right reasons.
The fact that I have spoken with two people in the past two weeks who relicensed their software shows that there are people out there choosing the GPL for reasons other than support of software libre.
This is entirely too funny. And sadly, too realistic. microsoft ipod packaging parody
