>> 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.
Not exactly. But you can contstrain setuptools to install eggs only from a specific directory or website, and forbid other sources. https://bitbucket.org/deets/easterbunny/src/882d2328438f/README > >[ 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. ] No, but TG2 works e.g. with SQLAlchemy 0.5 and 0.6. Your approach would prevent that from happening. >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. > > >> 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 !! > This doesn't happen for us, see above. We use a specialized version of EggBasket (a PyPI clone), but later I found out that we even didn't need to do that. All of our devs install different version-sets of eggs for different working-copies, e.g. when actually upgrading certain packages on a feature branch. Also ,deployment is easy, and allows for rolling back 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. Only if you happen to not have conflicting packages. And what happens if an OS-upgrade or installation of a 3rd-party tool pulls one in? That has crashed running systems more than once for us. And if you concede that you sometimes need venvs, why not go with it in the first place & save yourself the trouble? 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.
