> 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. > So is it possible to create a set of (config) files that "freezes" the dependencies at the time of release. And small doc update that can allow application developers and packagers to pick right set of dependencies. [ Btw, How to interpret RELEASE of a particular version of TG2 ? Does it mean that it will work with ANY future version of the dependent components ? We know that is not true. ] > >* 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/6f209b... > >) > > 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. > 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) > 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. > Yeah, but at the same time.. consider where each developer end up with different stack dependencies while each setting up their environment trying to install a particular version of TG2. This has actually happened with us.. and consumed considerable time. Similarly when QA sets up their environment they can get a different stack as well !! > 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. > This happens if there is no static definition of a particular version of TG2. In perfect world you would do your development against a particular version of TG2 and that means all dependencies having particular version. The same would be available from the distribution. So there should not be any difference. Now, I do understand that you might want to pick and choose some dependencies depending on either bug fixes or enhancements in that package. But you can make that choice *explicitly* and use mechanism like virtualenv. > 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. > No encouraging but, Thanks for the heads up :) > 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.
