problem installing TG 1.1 on ubuntu 10.04...

[nio]

Hello,

I'm new to TG and I'd like to install TG 1.1 on my xubuntu 10.04.

I've followed the documentation steps, I've installed easy_install,
virtualenv, activated my virtual_env, and then :
easy_install TurboGears
easy_install sqlalchemy

But when I try tg-amdin info, here's what I get :
/home/nio/pokepark/lib/python2.6/site-packages/CherryPy-2.3.0-
py2.6.egg/cherrypy/lib/cptools.py:3: DeprecationWarning: the md5
module is deprecated; use hashlib instead
import md5
/home/nio/pokepark/lib/python2.6/site-packages/CherryPy-2.3.0-
py2.6.egg/cherrypy/filters/sessionfilter.py:33: DeprecationWarning:
the sha module is deprecated; use the hashlib module instead
import sha
Traceback (most recent call last):
File "/home/nio/pokepark/bin/tg-admin", line 8, in <module>
load_entry_point('TurboGears==1.1.1', 'console_scripts', 'tg-
admin')()
File "/home/nio/pokepark/lib/python2.6/site-packages/
setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 318, in
load_entry_point
def get_metadata_lines(name):
File "/home/nio/pokepark/lib/python2.6/site-packages/
setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 2221, in
load_entry_point
"""Return a ``Requirement`` that matches this distribution
exactly"""
File "/home/nio/pokepark/lib/python2.6/site-packages/
setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 1954, in load
return entry
File "/home/nio/pokepark/lib/python2.6/site-packages/
TurboGears-1.1.1-py2.6.egg/turbogears/__init__.py", line 6, in
<module>
from turbogears.controllers import (absolute_url, expose, flash,
validate,
File "/home/nio/pokepark/lib/python2.6/site-packages/
TurboGears-1.1.1-py2.6.egg/turbogears/controllers.py", line 15, in
<module>
from peak.rules import abstract, always_overrides, Method,
NoApplicableMethods
ImportError: cannot import name always_overrides

I've googled and searched the groups and mailing lists, but I could'nt
find any solution...

And the messages doesn't give me any clue on the origin of the
problem...

Can somebody help me please ?

Thanks!

Nicolas.

[Diez B. Roggisch]

Am 13.08.2010 um 10:57 schrieb nio:

> Hello,
>
> I'm new to TG and I'd like to install TG 1.1 on my xubuntu 10.04.
>
> I've followed the documentation steps, I've installed easy_install,
> virtualenv, activated my virtual_env, and then :
> easy_install TurboGears
> easy_install sqlalchemy

Did you use virtualenv with the --no-site-packages directive? What does

>>> import peak.rules
>>> peak.rules.__path__

yield?

Diez

[nio]

Yes, I used the --no-site-packages directive...

Here is the result :

(pokepark)nio@nio-desktop:~/pokepark$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import peak.rules
>>> peak.rules.__path__
['/home/nio/pokepark/lib/python2.6/site-packages/
PEAK_Rules-0.5a1.dev_r2662-py2.6.egg/peak/rules']

[Diez B. Roggisch]

Looks good to me. All I can imagine is that you need a more specific
(probably older) version of PEAK rules.

Oh, and I'm not sure about the Python 2.6 compatibility of TG1.1 and
it's packages.

Diez

[nio]

> Oh, and I'm not sure about the Python 2.6 compatibility of TG1.1 and  
> it's packages.

Well, the official installation doc. states "Python 2.6.x is supported
from TurboGears version 1.0.9 and 1.1 onwards."...

And besides, I really have no idea on how to remove python 2.6 and
switch to python 2.5 !?!

[nio]

Ok, now I compiled Python 2.5, installed it along with Python 2.6
(needed for xubuntu 10.04), and I installed easy_install and
virtualenv for Python 2.5.

I then did again the installation procedure:

(pokepark)nio@nio-laptop:~/pokepark$easy_install TurboGears
...
(pokepark)nio@nio-laptop:~/pokepark$ tg-admin info

Traceback (most recent call last):
File "/home/nio/pokepark/bin/tg-admin", line 8, in <module>
load_entry_point('TurboGears==1.1.1', 'console_scripts', 'tg-
admin')()

File "/home/nio/pokepark/lib/python2.5/site-packages/
setuptools-0.6c11-py2.5.egg/pkg_resources.py", line 318, in
load_entry_point
File "/home/nio/pokepark/lib/python2.5/site-packages/
setuptools-0.6c11-py2.5.egg/pkg_resources.py", line 2221, in
load_entry_point
File "/home/nio/pokepark/lib/python2.5/site-packages/
setuptools-0.6c11-py2.5.egg/pkg_resources.py", line 1954, in load
File "/home/nio/pokepark/lib/python2.5/site-packages/
TurboGears-1.1.1-py2.5.egg/turbogears/__init__.py", line 6, in

<module>
from turbogears.controllers import (absolute_url, expose, flash,
validate,

File "/home/nio/pokepark/lib/python2.5/site-packages/
TurboGears-1.1.1-py2.5.egg/turbogears/controllers.py", line 15, in

<module>
from peak.rules import abstract, always_overrides, Method,
NoApplicableMethods
ImportError: cannot import name always_overrides

(pokepark)nio@nio-laptop:~/pokepark$ python --version
Python 2.5.5

... different version, same error...

[Christoph Zwerschke]

Am 13.08.2010 10:57 schrieb nio:
> I'm new to TG and I'd like to install TG 1.1 on my xubuntu 10.04.
>
> I've followed the documentation steps, I've installed easy_install,
> virtualenv, activated my virtual_env, and then :
> easy_install TurboGears
> easy_install sqlalchemy
>
> But when I try tg-amdin info, here's what I get :
>

> from peak.rules import abstract, always_overrides, Method,
> NoApplicableMethods
> ImportError: cannot import name always_overrides

Hi Nicolas, sorry for your bad first impression.

The problem is not with not using virtualenv or the Python version. TG
1.1 should work fine without virtualenv (even though it's recommended)
and with Python 2.6. You've just chosen a bad day to try it out: The
problem is caused by an API change in peak_rules made by Philip Eby just
yesterday in r2660.

It seems this change also broke the prioritized_methods package which is
used by TurboJson.

So the best fix for the time being is to install an older peak_rules
version, e.g PEAK-Rules-0.5a1.dev-r2659.tar.gz which you can find here:
http://peak.telecommunity.com/snapshots/

I will adapt TG 1.1 and 1.5 today so that it works with the new
peak_rules packages and try to get prioritized fixed as well.

-- Christoph

[nio]

Hi Christoph,

I did install the older PEAK-Rules and now tg-admin runs fine.

Thanks for your help !

Have a nice day.

-- Nicolas.

[Phillip J. Eby]

On Aug 13, 2:03 pm, Christoph Zwerschke <c...@online.de> wrote:
> Am 13.08.2010 10:57 schrieb nio:
>
> > I'm new to TG and I'd like to install TG 1.1 on my xubuntu 10.04.
>
> > I've followed the documentation steps, I've installed easy_install,
> > virtualenv, activated my virtual_env, and then :
> > easy_install TurboGears
> > easy_install sqlalchemy
>
> > But when I try tg-amdin info, here's what I get :
>

> >      frompeak.rulesimport abstract, always_overrides, Method,

> > NoApplicableMethods
> > ImportError: cannot import name always_overrides
>
> Hi Nicolas, sorry for your bad first impression.
>
> The problem is not with not using virtualenv or the Python version. TG
> 1.1 should work fine without virtualenv (even though it's recommended)
> and with Python 2.6. You've just chosen a bad day to try it out: The
> problem is caused by an API change in peak_rules made by Philip Eby just
> yesterday in r2660.
>
> It seems this change also broke the prioritized_methods package which is
> used by TurboJson.
>
> So the best fix for the time being is to install an older peak_rules

> version, e.gPEAK-Rules-0.5a1.dev-r2659.tar.gz which you can find here:http://peak.telecommunity.com/snapshots/

>
> I will adapt TG 1.1 and 1.5 today so that it works with the new
> peak_rules packages and try to get prioritized fixed as well.

Sorry about that - I'm trying to cleanly separate the API from the
internals; always_overrides is internal, and should be imported from
peak.rules.core, not from the parent package.

I can stick always_overrides back in if this is going to be a
widespread problem, but at some point it's got to go.

If it helps, I could push ahead on supporting inline priority() in
rules... ;-)

(See http://dirtsimple.org/2010/08/simplifying-prioritized-methods-in-peak.html
for details.)

>
> -- Christoph

[Phillip J. Eby]

On Aug 16, 5:01 pm, "Phillip J. Eby" <p...@telecommunity.com> wrote:
> I can stick always_overrides back in if this is going to be a
> widespread problem, but at some point it's got to go.
>
> If it helps, I could push ahead on supporting inline priority() in
> rules...  ;-)
>
> (See http://dirtsimple.org/2010/08/simplifying-prioritized-methods-in-peak.html
> for details.)

I went ahead and pushed out a new snapshot (r2672) with both a fix and
the new priority() feature. Sorry again about the mixup.

[Christoph Zwerschke]

Am 16.08.2010 23:35 schrieb Phillip J. Eby:
> I went ahead and pushed out a new snapshot (r2672) with both a fix and
> the new priority() feature. Sorry again about the mixup.

Thanks for the quick response, Phillip. I will use that feature in
TurboJson then.

-- Christoph

[Phillip J. Eby]

By the way, I was just writing something for my blog about avoiding
AmbiguousMethod errors *without* using priorities; I'm curious whether
it might help you. I was actually writing it based on the one jsonify-
like use case that I knew about that was causing ambiguous method
errors, and I just took a look at how TurboJson is using priorities.

Essentially, the issue is that you're putting what are basically your
fallback cases in rules, instead of in the main method body. If you
just put all your default cases in the main function body (instead of
using @abstract), then those rules can't ever be ambiguous.

But, if you *really* want to use rules to incrementally define your
default cases, just define them on an abstract "jsonify_default()"
function, then make a concrete jsonify like this:

def jsonify(ob):
return jsonify_default(ob)

Voila... you now have the equivalent of your "prio=-1" rules, while
any rules defined on jsonify() itself will have "higher priority", and
*can't* be ambiguous with any of your default rules.

Alternately, if the real issue is just conflicts with the lookup for
'__json__', you can do this:

@around(jsonify, "hasattr(ob, '__json__')")
def jsonify_explicit(obj):
"""JSONify objects with explicit JSONification method."""
return obj.__json__()

Then, you don't have to put in all those "and not hasattr" conditions
everywhere else, because the explicit version will always take
precedence if an object has the __json__ attribute.

So, I guess what I'm saying is that PEAK-Rules has *always* had
priorities -- they're just called "putting the base cases in the body"
and "use @around methods for things that need to take precedence over
everything else".

I'm wondering whether these would solve your problems without the use
of priorities.

[Phillip J. Eby]

Just to be clear, I should mention that, now that I've seen what
you're doing with it in TurboJson, the new priority() feature is *not*
appropriate for that use case.

That is, the new priority() does not allow you to define "lower-than-
normal" priorities. Until now, it honestly never occurred to me that
someone would need such a thing, since the One Obvious Way (but maybe
not so obvious if you're not me!) to do that would be to put those
rules in the main function body, or in a "default cases" generic
registered as the default case of the user-facing function.

[Christoph Zwerschke]

Am 17.08.2010 01:33 schrieb Phillip J. Eby:
> So, I guess what I'm saying is that PEAK-Rules has *always* had
> priorities -- they're just called "putting the base cases in the body"
> and "use @around methods for things that need to take precedence over
> everything else".

Well, sometimes you still may want to have more levels of priority.

Regarding TurboJson, you're right though, the existing functionality
should suffice and your ideas look like reasonable solutions to me. I'll
probably try to change TurboJson to work along these lines you pointed
out and see if I can get it done without breaking backward
compatibility. TurboJson was developed on rule-dispatch originally
(which didn't have an "around" iirc), and later people probably only
added upon that without really thinking about how to do it properly.

Your explanations and hints are highly welcome. It takes some time to
get a feeling for how to adequately apply generic functions.

Btw, while TG1 heavily relied on generic functions, TG2 does not use
them any more and also recently ditched TurboJson. I guess the reason is
that rule-dispatch and peak-rules can cause installation troubles, and
people seem to have difficulties to wrap their head around generic
functions generally. Maybe you need to do explain and advertize more ;-)

-- Christoph

[Phillip J. Eby]

On Aug 16, 8:48 pm, Christoph Zwerschke <c...@online.de> wrote:
> Am 17.08.2010 01:33 schrieb Phillip J. Eby:
>  > So, I guess what I'm saying is that PEAK-Rules has *always* had
>  > priorities -- they're just called "putting the base cases in the body"
>  > and "use @around methods for things that need to take precedence over
>  > everything else".
>
> Well, sometimes you still may want to have more levels of priority.

Btw, you can also now make your own method-based priority levels as
simply as:

class MyLevel2(Method): pass
when_level2 = MyLevel2.make_decorator()

class MyLevel3(Method): pass
when_level3 = MyLevel3.make_decorator()

class Default(Method): pass
when_default = Default.make_decorator()

(Around, Before, After) >> MyLevel3 >> MyLevel2 >> (Method,
MethodList) >> Default

The '>>' operator on method types defines a partial ordering graph,
though ordering is undefined between types you haven't explicitly
shown a precedence for. So the above says that Around, Before, and
After are higher precedence than all your new methods, and then those
are higher than Method/MethodList, and finally default. (You could
skip most of that if you just wanted to define a "when_default" for
defining all your non-around defaults.)

> Regarding TurboJson, you're right though, the existing functionality
> should suffice and your ideas look like reasonable solutions to me. I'll
> probably try to change TurboJson to work along these lines you pointed
> out and see if I can get it done without breaking backward
> compatibility.

Based on the mailing list posts I've been able to find, I think it
will be backward-compatible; if not, please let me know what you
find. Be sure to also see:

http://www.eby-sarna.com/pipermail/peak/2010-August/003382.html

If you haven't already.

> TurboJson was developed on rule-dispatch originally
> (which didn't have an "around" iirc), and later people probably only
> added upon that without really thinking about how to do it properly.

Or *asking*, either. ;-)

> Your explanations and hints are highly welcome. It takes some time to
> get a feeling for how to adequately apply generic functions.
>
> Btw, while TG1 heavily relied on generic functions, TG2 does not use
> them any more and also recently ditched TurboJson. I guess the reason is
> that rule-dispatch and peak-rules can cause installation troubles, and
> people seem to have difficulties to wrap their head around generic
> functions generally. Maybe you need to do explain and advertize more ;-)

Yes, I do. My recent blog post is a step in that direction; there
will be more leading up to the first official release.