“the key here is that the Pythonic way is typically to have an obvious solution, rather than a succinct one. TurboGears has always felt to me to be the other way around, more like Perl: you can do just about anything with it, often in a single line of code… if there was a hope in hell of you finding which line of code.”

This is a documentation issue. It is not a lack of Pythonicness… We do strive to have one “obvious” way to do something. But, it’s not obvious until you get the basic feel of the framework. The same is true of Python: once you get a feel for it, things become obvious. But, that doesn’t obviate the need for the library reference. You still have to know what methods and classes, etc. are called even when using Python with its stdlib.

For an example of what I mean: the “TurboGears way” is to make controller methods just simple, application-focused code as much as possible. The specification for how that method interacts with the web is done declaratively through decorators. Generally, the behavior of the decorators can be overridden by values returned by your controller method, but that’s the less-common case… we’ve optimized for the things people do all the time. Once you get into that, it becomes pretty natural to grab for the decorators…

Which is where the docs come in (or rather don’t come in enough right now).

I agree with folks above about sharing infrastructure and how WSGI helps here.

Michael: I’ve been using eggs for a year and I’ve witnessed how far they’ve progressed in terms of being easy to install. They’re not perfect, but I think they work quite well, especially once you’ve setup a distutils.cfg file to put things in the right place automatically.

Typing “easy_install ” isn’t a win because I would have a hard time installing that package. It’s a win because I don’t need to go to the cheeseshop, find the package, go to its home page (or the annoying sourceforge download pages), get the tarball, untar and finally run setup.py.

For TurboGears, you’d have to go through that drill a dozen times. For packages that do a really good job reusing code from others, this will not be uncommon. Instead, you get one command that picks up everything for you.

Additionally, setuptools provides the automatic plugin discovery mechanism… this makes widgets and template engines and Toolbox tools, etc. all show up without any additional configuration or installation into special locations.

I *will* grant that easy_install isn’t perfect for all cases. Jim Fulton did a good job explaining to me how eggs are a good solution for some of Zope Corp’s needs, but that easy_install isn’t quite what they need. So, they’ve created zc.buildout to use the egg format with some different constraints on how installation happens. It’s a cool and useful tool.

A few years ago when Perl was still quite big and generally had some buzz, people would criticize Python for lacking something like CPAN. The cheeseshop is only half of the solution. The CPAN perl module was key, because you could install a library with all of its dependencies in one go. easy_install does this for us in Python now. (Ruby has Gems, so they’ve gone after that issue too.)

I think setuptools is important. Sure, the implementation is not 100% perfect, and zc.buildout shows that some folks have different needs than what easy_install does. But, that doesn’t mean that it should be tossed. ]]> http://www.blueskyonmars.com/2006/08/19/there-cant-be-only-one/#comment-65250 Michael Dillon Fri, 25 Aug 2006 14:12:22 +0000 http://www.blueskyonmars.com/2006/08/19/there-cant-be-only-one/#comment-65250 The biggest problem with Turbogears is that it requires the easyinstall stuff to use it. I have run into so many problems with eggs and easyinstall that I refuse to use it anymore. If I can't find a straightforward tarball for a Python app, then I won't use it. Python is for developpers not endusers. A developper does not want an all-in-one install package that only allows you to install a package in the one true fashion. That's why I like tarballs, because I can install it where and how I want without disturbing any other parts of my system that I don't want to disturb. I use some of the components of Turbogears but I will never use Turbogears itself if it remains exclusively egg-based. The biggest problem with Turbogears is that it requires the easyinstall stuff to use it. I have run into so many problems with eggs and easyinstall that I refuse to use it anymore. If I can’t find a straightforward tarball for a Python app, then I won’t use it.

Python is for developpers not endusers. A developper does not want an all-in-one install package that only allows you to install a package in the one true fashion. That’s why I like tarballs, because I can install it where and how I want without disturbing any other parts of my system that I don’t want to disturb.

I use some of the components of Turbogears but I will never use Turbogears itself if it remains exclusively egg-based.

For instance, I would like to include a django created application in my zope server. And use kid templates in zope. Or include a zope based CMS inside turbogears. The key here is that there should be one and only one obvious way to do it.

On that account WSGI is a big step forward, but only for the interface of the webserver to the application server. The WSGI interface is too low level for application developers. What we need is a common interface at the application level. All frameworks provide a request object with form data end HTTP request info, a response object, a user object for security checks, a session object and an interface call a template. The functionality is exactly the same, but how to use it is very different for all the frameworks. For a language where “one way to do it” is a mantra, the situation is damn awkward.

In Java, the situation is much better. There people have the servlet API. Although there are many different implementations of that API (WebSphere, Tomcat, WebLogic), applications can be ported painlessly from one environment to the other. (Painless is relatively speaking of course, it still is Java, we are speaking of.)

If all frameworks use common interfaces for request, response, user, session objects and template interfaces we take a giant leap forward. There would hardly be a penalty in learning costs to switch between frameworks. It would allow a django app to forward a request to a zodb object and have the results formatted by a cheetah template.

But best of all, it would allow the development of framework independent libraries. For instance, zope contains a very powerful marshalling library. This allows fields in a complicated form to be mapped to integers, lists, records or combinations of the above. If there were a common request object, I could then rewrite this as a library that simply manipulates the data in the request object. It would instantly be useful in any of the other application frameworks.

So, it is not that there can be only one, but there should be only one way to do it.

However, one you start doing any kind of serious DOM-level manipulation (such as AJAX), you find that most of your effort is spent getting the DOM tree just right - making sure that all of the nodes are in the right place, that the children have the proper parents, and so on. Your mental conception of the document gradually changes until you are thinking of it more as a data structure than as a text document.

This is where rigorous structured templating comes in - its much better if errors in your document structure can be detected on the server side than having to rely on the haphazard error checking of Firefox, Safari or IE. Trying to rely on the browser’s error console (which half the time reports no error at all, the other half floods you with errors that are meaningless) to detect subtle structural errors is nighmarish to say the least. Better (and faster) to have a server-side template language that won’t *allow* you to make those kinds of mistakes.
——
Guido’s response was essentially “it may well be”…

I have been using TG since 0.5 and I love it! Django is very cool, but didn’t grab me and I have not yet been compelled to look at Ruby or Rails.

That said, Propad’s experience with installing TG has also been my own, even with 0.8.9 as well as 0.9x.

With unrestricted access to the net, TG is stupidly easy to install. This is true. Though you still have to know to get psyopg or sqlite or whatever. But offline, or behind a highly restricted proxy (like at my work), installing TG is a pain. I can do it, I’ve learned how, but it is a pain. I have also seen several posts on the mailing list asking about this.

I have the intent to contribute on this subject, but need the time.

I would like to suggest 2 things, though:

1) Put links to *all* dependencies on the download page, this includes Paste, PasteScript, PasteDeploy, Psycog, PySqlite, Formencode, etc. Everything, including docutils so the tutorial is flawless. Even if they are links offsite, that is fine but make it so that if I have to download everything manually, I can get it all in one place. This is a simple enough addition and I think it would go a long way for those of us stuck in highly restricted environments. Right now we have the equivalent of DLL/RPM hell.

2) I think (and I may have mentioned this elsewhere before) that a Plone-style installer (at least for Windows) that includes Python and everthing that TG needs would be very useful. Perhaps one without Python too. I know that there are a lot of people that use Python on Windows and making things easy for that demographic would go a long way to foster adoption.

I know suggestion 2 would need a champion, but number 1 would be fairly easy to do.

I feel bad not being able to commit to contributing… I want to… but I also believe that the manual install issue really does need to be addressed.

Anyway, I will end this long winded post and just reiterate that TG is absolutely wonderful! And once the docs are in place, things will be even better.

Keep up the awesome work and my sincerest thanks to you, Kevin, and everyone to has contributed to TG and it’s component projects!!!

Krys