I'm perhaps running buildout in a bit of unusual fashion (from my virtual env bin rather than the builds bin) and updated it recently from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh checkouts of one of my builds (see previous message). I was suprised when all my zc.recipe.cmmi deps were recompiled. not a huge deal due to the unusual circumstances, but seemed avoidable. I realize my upgrade is dependent on my virtualenv setup and was wondering if there is some standard way to upgrade a build's buildout version while avoiding unnecessary rebuilding. -w
On Jul 28, 2008, at 11:42 AM, whit morriss wrote:
I'm perhaps running buildout in a bit of unusual fashion (from my virtual env bin rather than the builds bin) and updated it recently from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh checkouts of one of my builds (see previous message).
I was suprised when all my zc.recipe.cmmi deps were recompiled. not a huge deal due to the unusual circumstances, but seemed avoidable.
I realize my upgrade is dependent on my virtualenv setup and was wondering if there is some standard way to upgrade a build's buildout version while avoiding unnecessary rebuilding.
Buildout is very conservative about rebuilding things -- erring on the side of rebuilding. IOW, if in doubt, builout will rebuild a part. When you upgrade buildout, it's possible that a change in buildout will affect how a part is built, so upgrading generally results on parts being rebuilt. There isn't currently a way to prevent this. Jim -- Jim Fulton Zope Corporation
whit morriss wrote:
I'm perhaps running buildout in a bit of unusual fashion (from my virtual env bin rather than the builds bin) and updated it recently from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh checkouts of one of my builds (see previous message).
as a caveat for others, we also noticed a number of older recipes which are cached don't take the new allowed hosts arg. It looks like older copies (in this case zc.recipe.egg) got installed in the virtualenv sitepackages (probably for the purposes of investigation) or egg caches and did not get updated. In systems like buildout where every buildout is necessarily a patch work of called dependencies (most frameworks or component systems are like this in one way or another, sometimes referred as what separates frameworks from libs), it would be useful to have some mechanism for propagate an update of a downstream component. Does setuptool support anything like this (I'm doubting it?)? could or does zc.buildout? for builds, I could see this being handled more as a migration. Update the framework library, run a migration to upgrade all the component libraries, rebuild. -w
On Jul 29, 2008, at 10:39 AM, whit morriss wrote:
whit morriss wrote:
I'm perhaps running buildout in a bit of unusual fashion (from my virtual env bin rather than the builds bin) and updated it recently from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh checkouts of one of my builds (see previous message).
as a caveat for others, we also noticed a number of older recipes which are cached don't take the new allowed hosts arg. It looks like older copies (in this case zc.recipe.egg) got installed in the virtualenv sitepackages (probably for the purposes of investigation) or egg caches and did not get updated.
This sounds like a bug. I expect buildout to get and use the newest distributions that satisfy its requirements regardless of whether older versions are in site-packages. One way that this would fail is if eggs are installed into site-packages as develop eggs, aka "single- version-externally-managed". buildout gives preference to develop eggs even if there are newer non-develop eggs. Distributions installed using -single-version-externally-managed are tagged by setuptools as develop eggs. I really wish setuptools made a distinction between single-version-externally-managed and develop eggs. Was the zc.recipe.egg distribution installed into your site- packages using -single-version-externally-managed? (This will be the case if the egg contents are stored directly in site-packages rather than having egg files or directories.)
In systems like buildout where every buildout is necessarily a patch work of called dependencies (most frameworks or component systems are like this in one way or another, sometimes referred as what separates frameworks from libs), it would be useful to have some mechanism for propagate an update of a downstream component.
By "downstream", do you mean a dependency?
Does setuptool support anything like this (I'm doubting it?)? could or does zc.buildout?
for builds, I could see this being handled more as a migration. Update the framework library, run a migration to upgrade all the component libraries, rebuild.
As a general rule, buildout always tries to find the latest versions of all distributions used, including dependencies. One exception to this is that it prefers develop eggs. Jim -- Jim Fulton Zope Corporation
participants (2)
-
Jim Fulton -
whit morriss