On Saturday 13 June 2009 20.59:07 Diez B. Roggisch wrote: > Adrian von Bidder schrieb: > > Hi, > > > > On Friday 12 June 2009 20.46:36 Dan F wrote: > >> It seems like there are a lot of steps to undertake before starting a > >> turbogears app, no matter what the platform. I'd like to start > >> developing a rather basic gui app that can simplify it and I wonder > >> what you all think. > > > > For production use, I much prefer to have tg integrated in the Linux > > distribution instead of having to download it separately. There is a > > packaging effort going on to bring tg2 into Debian, and as a system > > administrator, maintaining a tg2 installation with the distribution > > tools is easier than having to deal with an application specific > > installer. > > > > For development, the situation is different, since one probably wants > > to develop against a newer tg version than what is available in a > > distribution and so using a virtualenv is probably the sensible thing > > to do. So if there's an installer that makes that easy, why not. > > That's a wrong assumption. Getting development & production as close as > possible must be the goal. What good is it to have a newer development > version that is bug-fixed, but then on production things fall to pieces?
I assumme that by the time the project nears deployment, the libaries I depend on also are more or less stable, and thus in packagable state. Having just one installation system is essential to efficiently being able to install security fixes. (It's similar to the situation distribution faced when xpdf had security issues: every app reading pdf files had their own copy of the xpdf code, in various versions. Security support was hell. So poppler was created and now most apps use it, so a new pdf reader security issue requires mostly just libpoppler to be updated.) > And while in theory package management is a nice thing, it falls flat on > it's face because of package-dependencies that are mutually > incompatible. Take for example matplotlib under debian that comes with a > specific version of configobj - which might conflict with TG. Unstable library APIs like this are IMO a serious problem and should be fixed. I agree that currently, this may not always be possible in the short term, but I hope that module developers will commit to stable APIs as the various components stabilize. We [the Unix world in general] took 20 years to solve this problem with C libraries via the soname mechanism. Do we have to take 20 years now for every new language to learn the same lesson? > Also, the release-cycles of a great many python-packages (including of > course TG2 and it's vast amount of dependencies) are much shorter than > the ones of the various linux distros. So either you are stuck with an > horribly outdate version, or your existing software gets to run on a > changed stack just because of the next sys-updated being run. No, thank > you. Fast pace in development of a framework is nice for developers, but when I deploy a web applications, I need stability for a few years. I don't have the resources to constantly tinker with it to keep it up with the whims of API changes of the latest version. At the same time, I still need security support. Debian promises API stability within its security update mechanism, so when I develop against a squeeze-packaged tg2 and deploy a webapp on it, I get security support for this app and this API until squeeze+1 is released plus about a year. And this means I get a year to update my deployed webapp to whatever version is in squeeze+1, which again will be security supported. With VEs and a myriad different incompatible library versions, I will have to be closely involved with all of the components and track their versions. This works fine if you run and develop one or a few apps and are involved with them. This falls flat on its face if you're a sysadmin who took over running a service from the developers and are charged with keeping it running. The sysadmin may be able to install an egg into a VE, but he probably doesn't know the framework, and he certainly isn't involved enough with the commmunity to decide which component he should update for security support, and which component must not be updated because it breaks API stability. > I don't see any alternative from VEs. And they work great for us. They work for developers. They don't work for sysadmins. cheers -- vbi -- featured product: Debian GNU/Linux - http://debian.org
signature.asc
Description: This is a digitally signed message part.
