> 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.
And this assumption is based on what? Wishing really hard it would be that way? > 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. Again, on what precedent do you groud that hope? We are talking web-frameworks here, which tend to incorporate a lot of "cutting edge" technology. In contrast, the feature freeze of lenny, the current stable of debian (and thus a dream of every sysadmin) was *one year ago*. So no TG2 for how long - 2 or 3 years? > > 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? What problem is solved? There are RPMs, debs, and tgz-based packages of gentoo if I'm not mistaken. There are various distributions build on top of that, with incompatible packages between them. And all of this is only talking Linux. What about OSX, Windows in various variants, and other *nixes? This problem is *far* from being solved. And I don't see it as responsibility of Python (or any other languages) developers to cater to all these different needs, just because somebody dreams up the next package management to rule them all. Don't get me wrong, I'm a Linux user for >14 years now, and debian for 8 or so. And I'm thoroughly impressed and enjoy package management based software installation every day. And I applause those who maintain the packages. But it doesn't work properly for the fast-paced development that happens right now in TG, or other fields of python. My debian carried a *severly* broken setuptools-version for *months*, leaving me no choice to remove it it as deb - resulting in a great deal of other depending packets to be removed as well. > 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. if developers use the current versions, *they* do the tinkering. OTOH, *not* caring about the framework versions yourself and instead hoping that package-based distributions keep the API stable themselves is just that - hoping for the best. It might succeed, it might as well not. Of course distributions strive for maintaining secure and api-stable releases. But this needs a dedicated developer for each package & distribution who can incorporate security bugfixes without introducing incompatible APIs. Which needs thourough testing, and potentially lot of work if the main release has moved on considerably. Who shall that be for the plethora of libraries and frameworks out there? So if distributions instead rely on fixed upstream-releases, they might break your software. > 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. Losing all improvements of TG2 in the meantime? And hoping that the frozen version is not only secure, but also not bug-ridden? > 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. > > They work for developers. They don't work for sysadmins. Wrong. We use them, they work. I'm responsible not only for developing our webapp, but also for developing the deployment system it works on. It works very well, making transitions between frozen version sets easy, and possible in both directions in case something is not working with a new release. The only frequent issue is the one of binary packages being not available for windows or osx (our production system is running linux) Granted, I wish we hadn't had to invest the time we had to and instead could have picked a ready solution from the FOSS-shelf. But if anything, I think and believe that this problem can only be solved within python. VEs are a starter, PIP and zc.buildout go even further, as does our own eggbasket-based approach. But waiting for this to work based upon a grand unified package management system that works OS and distribution-independend is nothing but wishful thinking in my eyes. Diez --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
