[Grok-dev] Re: newbie grokproject installation problems

[Martijn Faassen]

Hey,

felis wrote:

> What is zip_safe, where can i set the flag to what? Is this flag the reason
> installing takes so long?
> Why aren't the svn urls picked up, what can i do to make them work?
> Why doesn't grokproject install mechanize?

Unfortunately not all of this output is actually a real problem. I'll 
explain the bits below.

> After this error i'm left dangling, i don't know if grokproject installed my
> project or not? What can i try next?

[snip]

> Downloading zc.buildout...
> Invoking zc.buildout...
> zip_safe flag not set; analyzing archive contents...

Don't worry about this report, it seems to be harmless.

> zc.zope3recipes.debugzope: module references __file__

This one is a harmless warning as well.

> Download error: unknown url type: svn -- Some packages may not be found!

You can ignore this one as well; I believe it's when a package refers to 
its home page using a svn: URL. setuptools tries to follow these but 
cannot interpreter 'svn://'. That's fine though, as there's really 
nothing there for it to find.

[snip]

Now comes the real error:

> While:
>   Installing app.
>   Getting distribution for 'mechanize==0.1.7b'.
> Error: Download error for
> http://wwwsearch.sourceforge.net/mechanize/src/mechanize-0.1.7b.zip: (104,
> 'Connection reset by peer')

'mechanize' is one of the dependencies of Grok. Unfortunately 
mechanize's package is not nicely stored on PyPI itself, see here:

http://pypi.python.org/pypi/mechanize

There's no .tgz to download there. In response setuptools (which is used 
by buildout) will follow to the project's home page and tries to 
interpret it:

http://wwwsearch.sourceforge.net/mechanize/

On it, it finds a URL to the zip file (which it for some reason prefers 
above the .tgz here. Not sure why):

http://wwwsearch.sourceforge.net/mechanize/src/mechanize-0.1.7b.zip

For some reason, when you were running buildout, your computer wasn't 
able to access that file. When I try now by hand, I can. It may be that 
sourceforge was flaky; wouldn't be the first time.

You can try again by running grokproject again, *or* you may have luck 
in finalizing the project just created by changing into the directory 
that grokproject created (with the name of the project you gave it), and 
running:

bin/buildout

as often as it stops erroring out on unfound files. :)

Anyway, this kind of installation problem makes me think we should 
really be fixing up Python package index itself to download versions 
into it, or maintaining our own KGS-like index. KGS itself doesn't 
entirely solve this problem though, as it also maintains the same link 
to the homepage of the package in question...

Regards,

Martijn