[Grok-dev] grokproject/buildout problems

Martijn Faassen faassen at startifact.com
Thu Sep 4 07:21:45 EDT 2008


Maurits van Rees wrote:
[snip]
>> * "eggbasket: Failed to install required eggs with the tar ball. 
>> Continuing with buildout instead." (duplicated). After this "continuing 
>> with buildout instead" doesn't do anything - it just stops here. We 
>> don't end up with a working buildout!
> 
> No idea.  Do you mean it ends and you are back on the command line?
> Or is it still continuing without printing anything, probably heading
> for a timeout while trying to download something?

No, it just ends and I'm back at the command line.

>> * Because I happen to know what's up with buildout, I run 
>> 'bin/buildout'. It seems to be getting the docutils 0.4 distribution 
>> online for some reason - why isn't this in the eggbasket tarball? Or 
>> perhaps it is and it isn't picked up for some reason? The whole point of 
>> it after all is to avoid such dangerous side-trips to sourceforge..
> 
> It is not in the tarball.  Okay, this is strange.  When I create the
> grok 0.13 tarball (bin/bundlemaker in the grok trunk checkout) I get
> these differences with the original tarball:
> 
>   < grok-eggs-0.13/ClientForm-0.2.7.zip
>   ---
>   > grok-eggs-0.13/ClientForm-0.2.7.tar.gz
>   > grok-eggs-0.13/docutils-0.4.tar.gz
> 
> The zip instead of tar.gz is fine with me.  But for some unknown
> reason docutils is not included in our official tarball.  Running the
> bin/bundlemaker normally or from a virtualenv with --no-site-packages
> made no difference.

Hm, I wonder how we can move forward with this. I guess a Grok 0.13.1 
release would be the safest way forward, and then we supply a new tarball.

[snip]
>> * "eggbasket: Failed to install required eggs with the tar ball. 
>> Continuing with buildout instead." Does it not pick up the stuff in 
>> .buildout/eggs? Do we need a separate one per virtual env? If we use 
>> virtualenv anyway (it looks more and more inevitable and we already 
>> recommend it in various places), can we do away with our egg cache there 
>> altogether and simply use the virtual env's site-packages?
> 
> eggbasket looks in the specified eggs_directory to see if the required
> grok version and its dependencies are installed there.  If not, it
> gets the big tarball.

Yes, I understand, but I get this message when I switch to another 
virtual env for some reason. You'd think it'd find the same eggs 
directory. We need to do some more experimenting with this.

>> * Even after this it takes forever, still not outputting what it is 
>> doing. I happen to be on a slow network right now so I probably notice 
>> these problems more quickly. When I run grokproject twice while in the 
>> same virtualenv, starting without .buildout directory, grokproject 
>> *does* run quickly the same time. I wonder what causes this...
> 
> The second time it *does* have a filled .buildout/eggs directory,
> right?  Then it is logical.

The first time around it already has the .buildout/eggs directory - it 
was just created from a different virtual env. For some reason the 
system takes a long time even when it's already there.

Thanks for the quick feedback!

I guess we should make issues for all the eggs that generate weird 
output so we don't forget to talk to the owners. Volunteers to add these 
to launchpad? (and check whether newer releases already have it fixed, 
and if not, approach their maintainers? :)

Regards,

Martijn



More information about the Grok-dev mailing list