-----Ursprüngliche Nachricht----- Von: "Toshio Kuratomi" <[email protected]> Gesendet: 03.01.2011 23:59:23 An: [email protected] Betreff: Re: [TurboGears] Re: TurboGears joins the PylonsProject
>On Mon, Jan 03, 2011 at 09:36:22PM +0100, Diez Roggisch wrote: >> >Distribution is one of the axis considered for choosing a development >> >platform. We have heard from multiple consumers that egg files >> >deployment and management is not acceptable and they would consider >> >the product only if it is available in .rpm or .deb package format. >> > >> >Even from developers point of view, being able to get an environment >> >where they can start getting their hands wet is also important. (See >> >wiki updates on documents on the install page the number of updates >> >and workarounds for people to get TG2 stack installed) >> >> We have developers up and running (if they have a working linux) in under >> half an hour. >> >> And of course a DEB or RPM is nice, if that's the way you chose to deploy. >> But that has nothing to do with my point. You can certainly create a DEB >> containing a full versionset, with dependend eggs. The problem is to try & >> use the shipped dependencies of your distro. That's a desaster waiting to >> happen. >> >Generalizations are bad because they ignore that there's different needs >that different strategies are geared for and the different tools that >underly those strategies. This discussion is in the context of TG2 development and deployment. > >If you're creating a web application for use inside of an organization where >you're also the full-time sysadmin for the service, virtualenvs may be the >best way to manage that. I'm not the sysadmin. But I am of course working together with him. And he's quite happy with the solution so far :) > >If you're handing off to a dedicated IT department that deploys to a stable >system (one where API compatibility is ensured even when packages are >updated), building to use the system packages that will be available on that >system may be a requirement imposed by IT. It may be a requirement imposed by IT, but then it's not or only very hard fulfillable in the context of TG2. Take the current ubuntu LTS (certainly a preferred choice for setting up a production system today). It contains zope.sqlalchemy, which is needed by TG2: https://launchpad.net/ubuntu/lucid/+package/python-zope.sqlalchemy The stable (LTS!!!!) version here is 0.4-7. Now let's take a look what a recent TG2 installation of a small project of mine: tequila:home deets$ ll ~/.virtualenvs2.5/wordpuzzle/lib/python2.5/site-packages/ | grep zope.sqlalch drwxr-xr-x 4 deets staff 136 Oct 31 22:05 zope.sqlalchemy-0.6-py2.5.egg/ Bummer. Two minor version numbers higher. So I can't go with the distro's version. I possibly event can't chose to not install it, as it might be a dependency of some other tool that needs in in that very version. My solution here is to use a virtualenv, with --no-site-packages option to prevent sys.path pollution. Which is yours? >If you're developing an application that will be released for people in many >different organizations to run (for example Drupal or mediawiki [Is it bad >that all the apps that I can think of that fit this role off the top of my >head are php? :-( ]) then you have to write code that can deal with a wide >variety of different versions since the route most users will take to get >this software will be what's packaged for their operating system. > >A little unrelated, putting all of the eggs you depend on into a single >deb/rpm really is a recipe for disaster as it means that you need to manage >the builds for all of the packages should you need to make changes to just >one. It's much better to take the packages from your distro and modify them >to suit your needs and then create a package repository to pull your packages >from. That way you: 1) Gain the benefit of seeing how your system >maintainers have built their packages to work around quirks that they've >discovered in each of the packages. 2) When you discover something that you >must fix, you're able to fix only that one package and issue an update >rather than updating everything in the rpm, possibly introducing unexpected >changes. You see, all of this is fun & nice on a meta-level. But so far, whenever this discussion has crept up here or on c.l.py or wherever, it was just on exactly that level. I OTOH have to solve (and solved) the actual problem. I'm happy to be convinced that there is a better way that is more conformant with the OS dependency management. So far, the only alternative I've been pointed to is using zc.buildout - which goes even *further* in not only providing eggs, but instead building whole libraries, including python itself. So given the above example, how would you go about this? - start creating a DEB package - manage to install it without provoking a conflict with the system's version - manage to have it picked up when starting the TG2-app which requires it Bonus points for pointing out how you still benefit from the original zope.sqlalchemy package being under distro control, getting potential bug and security fixes (for the otherwise outdated version). Diez ___________________________________________________________ NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://produkte.web.de/go/webdefreephone -- 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.
