>We have been using TG2 2.0.3 version for our OSS product for a while >and have been overall satisfied. Have few comments and questions that >we hope would be taken in the positive spirit. > >* Labeling dependencies on release : This has been biggest pain for >us. i.e When we depend on TG2 2.0.3 stack,, we expect that all >dependencies are frozen, this way we can develop, test and release the >product against a particular stack. TG2 itself having dependencies >"foo >= x.x." should be changed to "foo = x.x" once the framework is >labeled/released. (I know that this is multilevel and all components >dependencies also need to be made fixed, but doing this seems right at >"providing framework"/TG2/Pyramid level). We support our application >on a wide variety of linux platforms, having atleast dependencies >fixed will cut down one axis of complexity. I hope something like this >can be done in upcoming TG2 releases as well as the new Pyramid >project.
The current approach of index-pages takes pretty much care of that. And I don't think your suggestion is viable. It makes it impossible to update dependencies without an explicit release of TG2 itself. Using setup.cfg to constrain setuptools to fetch only specific versions of packages is easy enough, and allows for the individual flexibility needed. >* This will also allow other contributors to package TG2 properly and >build application packages that can be easily tested/validated and >packaged. > ( and not run in to issues like >http://groups.google.com/group/turbogears/browse_thread/thread/6f209bd6a22d66c5/791918d036f1e1b4?lnk=gst&q=Ubuntu+10.10#791918d036f1e1b4 >) > Making turbogears/Pyramid available and installable via native >commands like yum/apt-get is huge positive point for the product. I beg to differ. It is a big positive point for products that depend on it, alas existing web-apps that are released. AFAIK some red-hat stuff is based on TG1. It's not a positive point for ongoing development of your own app. You are stuck with out-dated and possibly buggy versions because of the release-policies for a OS-distro. The numbers of times where system-installed packages broke our development are countless. So either we have to remove pulled in dependencies of e.g. zope.transaction, or use virtualenvs with --no-site-packages. I understand the desire of a one-size-fits-all package management. It's just not realistic, at least right now. >* It is mentioned that new work will be undertaken under Pyramid >project. Is there going to be a way to move a TG2 project to Pyramid ? >This way we can take advantage of new enhancements in made available >down the line. Do we know what this is going to look like ? I'm not part of the TG3 (in lieu of a better name) efforts, but from previous experience with TG1 + TG2 I say: don't hold your hopes up high on this. Being backwards-compatible is difficult even in linear development. Switching horses on the go (as the move to repoze.bfg essentially means) makes it nightmarish. You have to weigh the benefits of moving to a new stack & rewriting parts of your code vs. just keep on going with a working system. I *hope* test-code is migratable. If anything, that would be where I'd put effort into. Because then you can cover you app with tests, and see if & which break after a transition. Diez ___________________________________________________________ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 -- 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.
