Fear, Frustration and Despair
Thomas Weholt
recently I've become more and more sceptical about using it. It's ok to
build a framework on third-party modules, but in turbogears this is
beginning to look crazy. Just look at the list of packages listed at
http://www.turbogears.org/download/index.html. I don't know how many of
these you absolutely need to get turbogears running, but all my
attempts at downloading the latest release have failed lately because
of some missing third-party module or something that won't compile.
This was no problem in the start of the project. It was a brilliant
showcase of good use of setuptools. If there's a way around this, to
download just the core modules you need to get started it should be
better documented on the homepage. And as more and more users switch to
python 2.5 turbogears lags behind because alot of the third-party
modules aren't 2.5-compatible.
I've also tried to keep track of the progress of Turbogears using the
trac.turbogears.org-site, but the roadmap shows little or no progress
lately. Are there being done any serious work on the core issues?
Sorry, if this seems like just complaining, and you can say "Why don't
you dive into the code, fix the bugs, contribute patches etc." all you
want. I've been sitting on the fence waiting for turbogears to reach
1.0, be easy to download and use and then suggest it as an alternative
to .NET-based solutions at my workplace. My first encounter with
turbogears was love at first sight so I really want turbogears to be a
success.
I wish my timeschedule allowed me more time to work on projects like
this, then maybe I could really contribute and help solve some of the
issues I've mentioned here. Many of you guys probably have the same
problem. But anyway, keep up the good work. I *do* appreciate the work
you do, even if this message might make you think I don't.
Timur Izhbulatov
>
> I've been a fan of Turbogears since the first announcement, but
> recently I've become more and more sceptical about using it. It's ok to
> build a framework on third-party modules, but in turbogears this is
> beginning to look crazy. Just look at the list of packages listed at
> http://www.turbogears.org/download/index.html. I don't know how many of
> these you absolutely need to get turbogears running, but all my
> attempts at downloading the latest release have failed lately because
> of some missing third-party module or something that won't compile.
> This was no problem in the start of the project. It was a brilliant
> showcase of good use of setuptools. If there's a way around this, to
> download just the core modules you need to get started it should be
> better documented on the homepage. And as more and more users switch to
> python 2.5 turbogears lags behind because alot of the third-party
> modules aren't 2.5-compatible.
I believe TG *can* be modularized. But can this be done in backward-compatible
way?
> I've also tried to keep track of the progress of Turbogears using the
> trac.turbogears.org-site, but the roadmap shows little or no progress
> lately. Are there being done any serious work on the core issues?
>
> Sorry, if this seems like just complaining, and you can say "Why don't
> you dive into the code, fix the bugs, contribute patches etc." all you
> want. I've been sitting on the fence waiting for turbogears to reach
> 1.0, be easy to download and use and then suggest it as an alternative
> to .NET-based solutions at my workplace. My first encounter with
> turbogears was love at first sight so I really want turbogears to be a
> success.
>
> I wish my timeschedule allowed me more time to work on projects like
> this, then maybe I could really contribute and help solve some of the
> issues I've mentioned here. Many of you guys probably have the same
> problem. But anyway, keep up the good work. I *do* appreciate the work
> you do, even if this message might make you think I don't.
--
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIz...@oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com
Diez B. Roggisch
While I can understand your frustration because of what happened to you, I
must say that I've personally installed TG on a few machines easy-peasy with
easy_install TurboGears
That was it. So - nope. Can't say that there is anything to get better from my
POV.
--
>> Diez B. Roggisch
>> Developer
T +49 (30) 443 50 99 - 27
F +49 (30) 443 50 99 - 99
M +49 (179) 11 75 303
E diez.r...@artnology.com
>> artnology GmbH
A Milastraße 4 / D-10437 Berlin
T +49 (30) 443 50 99 - 0
F +49 (30) 443 50 99 - 99
E in...@artnology.com
I http://www.artnology.com
Jorge Vargas
>
> I've been a fan of Turbogears since the first announcement, but
> recently I've become more and more sceptical about using it. It's ok to
> build a framework on third-party modules, but in turbogears this is
> beginning to look crazy.
that's why you have setuptools to do it for you :)
> Just look at the list of packages listed at http://www.turbogears.org/download/index.html.
I agree that list looks big but those are all the packages TG may
need, also see that many versions of the same package are in there. I
believe someone is working on adding to easy_install a list command
that will tell you exactly which packages are needed for X install.
I don't know how many of
> these you absolutely need to get turbogears running, but all my
> attempts at downloading the latest release have failed lately because
> of some missing third-party module or something that won't compile.
OS? are you upgrading? maybe we are missing one of the binary eggs.
> This was no problem in the start of the project. It was a brilliant
> showcase of good use of setuptools. If there's a way around this, to
> download just the core modules you need to get started it should be
> better documented on the homepage. And as more and more users switch to
> python 2.5 turbogears lags behind because alot of the third-party
> modules aren't 2.5-compatible.
>
yes this is a concern http://docs.turbogears.org/1.0/Python2.5Support
currently our biggest drag back is ruledispatch which
http://groups.google.com/group/turbogears-trunk/browse_frm/thread/471d28a3dcaaa18a
is already 2.5 compatible.
I believe the only thing left for the full migration is someone that
sits and says "yes it's working"
> I've also tried to keep track of the progress of Turbogears using the
> trac.turbogears.org-site, but the roadmap shows little or no progress
> lately. Are there being done any serious work on the core issues?
>
actually the core issues right now are in docs.turbogears.org most of
the tickets at trac are small fixes and many many suggestions. I do
have to agree that I'll like to see more activity there.
> I wish my timeschedule allowed me more time to work on projects like
> this, then maybe I could really contribute and help solve some of the
> issues I've mentioned here. Many of you guys probably have the same
> problem. But anyway, keep up the good work. I *do* appreciate the work
> you do, even if this message might make you think I don't.
something as simple as pointing out where stuff needs to be done is a
good help, even go into trac and say I try this patch and it works ok
or I'll like this to be implemented is a big contribution
Kevin Dangoor
>
> I've been a fan of Turbogears since the first announcement, but
> recently I've become more and more sceptical about using it. It's
> ok to
> build a framework on third-party modules, but in turbogears this is
> beginning to look crazy. Just look at the list of packages listed at
> http://www.turbogears.org/download/index.html. I don't know how
> many of
> these you absolutely need to get turbogears running, but all my
> attempts at downloading the latest release have failed lately because
> of some missing third-party module or something that won't compile.
This is part of the reason why I created the new tgsetup script. It
removes some more details.
In fact, the plan is for there to be *more* dependencies, not
fewer... because, we're breaking more parts of TurboGears itself into
reusable parts (like the widgets).
> This was no problem in the start of the project. It was a brilliant
> showcase of good use of setuptools. If there's a way around this, to
> download just the core modules you need to get started it should be
> better documented on the homepage.
The download page needs to change to just say this:
1. Install Python
2. Download tgsetup.py
3. Run tgsetup.py
That's it.
> And as more and more users switch to
> python 2.5 turbogears lags behind because alot of the third-party
> modules aren't 2.5-compatible.
Actually, Pyrex has been the main holdup. As Jorge mentioned, at this
point we should be able to make things work with 2.5, but someone
needs to try it out.
> I've also tried to keep track of the progress of Turbogears using the
> trac.turbogears.org-site, but the roadmap shows little or no progress
> lately. Are there being done any serious work on the core issues?
A few people have gone in and helped clean things up a lot. Some
issues will get attention and others won't... it's all a question of
what people's priorities are.
If someone steps forward on the turbogears-trunk list and says "I
want to fix this bug, any pointers?" I think they'd get some useful
help and get the bug fixed.
> Sorry, if this seems like just complaining, and you can say "Why don't
> you dive into the code, fix the bugs, contribute patches etc." all you
> want. I've been sitting on the fence waiting for turbogears to reach
> 1.0, be easy to download and use and then suggest it as an alternative
> to .NET-based solutions at my workplace. My first encounter with
> turbogears was love at first sight so I really want turbogears to be a
> success.
Things are getting cleaned up, docs are getting cleaned up and put
together and tgsetup eliminates a bunch of installation hassle. There
are probably a couple more bugs that absolutely must get fixed, but
otherwise I think the product is pretty good.
> I wish my timeschedule allowed me more time to work on projects like
> this, then maybe I could really contribute and help solve some of the
> issues I've mentioned here. Many of you guys probably have the same
> problem. But anyway, keep up the good work. I *do* appreciate the work
> you do, even if this message might make you think I don't.
It's always good to hear both the good and bad of people's
impressions of our software. Thanks for sharing!
Kevin
Michael Steinfeld
[agile@mini Desktop]$ tg-admin quickstart foo
Traceback (most recent call last):
File "/usr/local/bin/tg-admin", line 7, in ?
sys.exit(
File "/usr/lib/python2.4/site-packages/setuptools- 0.6c3-py2.4.egg/pkg_resources.py", line 236, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.4/site-packages/setuptools-0.6c3-py2.4.egg/pkg_resources.py", line 2097, in load_entry_point
return ep.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6c3-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/__init__.py", line 21, in ?
ext = entrypoint.load()
File "/usr/lib/python2.4/site-packages/setuptools- 0.6c3-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/usr/lib/python2.4/site-packages/Myghty-1.1-py2.4.egg/myghty/importer.py", line 54, in import_module
return builtin_importer(name, globals, locals, fromlist)
ImportError: No module named tgfastdata.plugin
</snip>
what I will probably do to remedy this, is install python2.4 manually, I am guessing that something is up with the python default install with FC6. Also note that I tried using 'Yum' to install which again worked fine, but would not let me run tg-admin.
I am not saying this to complain at all, I will remedy it. I am just letting you guys know that there are issues with FC6 and TG.
Mike
On Nov 14, 2006, at 9:07 AM, Thomas Weholt wrote:
>
> I've been a fan of Turbogears since the first announcement, but
> recently I've become more and more sceptical about using it. It's
> ok to
> build a framework on third-party modules, but in turbogears this is
> beginning to look crazy. Just look at the list of packages listed at
> http://www.turbogears.org/download/index.html . I don't know how
--
-mike
Jorge Vargas
> File
> "/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/__init__.py",
> "/usr/lib/python2.4/site-packages/Myghty-1.1-py2.4.egg/myghty/importer.py",
> ImportError: No module named tgfastdata.plugin
did you install the fastdata extension?
by any change this code was created with a TG 0.8* release?
>
> what I will probably do to remedy this, is install python2.4 manually, I am
> guessing that something is up with the python default install with FC6.
> Also note that I tried using 'Yum' to install which again worked fine, but
> would not let me run tg-admin.
>
> I am not saying this to complain at all, I will remedy it. I am just letting
> you guys know that there are issues with FC6 and TG.
it may be, can you check if the FC6 packages use setuptools?
one thing that you should know is that setuptools enable packages
doesn't recognize non-setuptools packages, but they can be installed
as plain distutils modules, so many packaging systems install
setuptools modules what won't work with setuptools ... ironic isn't
it?
Michael Steinfeld
On 11/14/06, Michael Steinfeld <mikei...@gmail.com> wrote:
> File
> "/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/__init__.py",
> "/usr/lib/python2.4/site-packages/Myghty-1.1-py2.4.egg/myghty/importer.py",
> ImportError: No module named tgfastdata.plugin
ok I see 3 things here are you using other then kid templates?
did you install the fastdata extension?
by any change this code was created with a TG 0.8* release?
nope, I installed python2.4 via yum ( /usr/local/bin ) then added /usr/local/bin in my bash profile ahead of all paths on $PATH so that it would default to /usr/local/bin/python instead of /usr/bin/python. Then I installed with 'python tg-setup.py' that I downloaded from turbogears.org
>
> what I will probably do to remedy this, is install python2.4 manually, I am
> guessing that something is up with the python default install with FC6.
> Also note that I tried using 'Yum' to install which again worked fine, but
> would not let me run tg-admin.
>
> I am not saying this to complain at all, I will remedy it. I am just letting
> you guys know that there are issues with FC6 and TG.
it may be, can you check if the FC6 packages use setuptools?
one thing that you should know is that setuptools enable packages
doesn't recognize non-setuptools packages, but they can be installed
as plain distutils modules, so many packaging systems install
setuptools modules what won't work with setuptools ... ironic isn't
it?
sorry, I didn't quite understand you there, but I think I get the gist of what you are saying.
What I am going to do is a clean install with a fresh version of python and TG and I will let you know how that goes.
but the point is, I should not have to do that and there should be some sorta comment about FC6 and tgsetup.py.
--
-mike
Kevin Dangoor
On 11/14/06, Jorge Vargas <jorge....@gmail.com> wrote:
On 11/14/06, Michael Steinfeld <mikei...@gmail.com> wrote:
> File
> "/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/__init__.py",
> "/usr/lib/python2.4/site-packages/Myghty-1.1-py2.4.egg/myghty/importer.py",
> ImportError: No module named tgfastdata.plugin
ok I see 3 things here are you using other then kid templates?
did you install the fastdata extension?
by any change this code was created with a TG 0.8* release?
nope, I installed python2.4 via yum ( /usr/local/bin ) then added /usr/local/bin in my bash profile ahead of all paths on $PATH so that it would default to /usr/local/bin/python instead of /usr/bin/python. Then I installed with 'python tg-setup.py' that I downloaded from turbogears.org
Toshio Kuratomi
>
>
> On 11/14/06, Jorge Vargas <jorge....@gmail.com> wrote:
>
> On 11/14/06, Michael Steinfeld <mikei...@gmail.com> wrote:
> > File
> >
> "/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/__init__.py",
> >
> "/usr/lib/python2.4/site-packages/Myghty-1.1-py2.4.egg/myghty/importer.py",
> > ImportError: No module named tgfastdata.plugin
> ok I see 3 things here are you using other then kid templates?
> did you install the fastdata extension?
> by any change this code was created with a TG 0.8* release?
>
> nope, I installed python2.4 via yum ( /usr/local/bin ) then
> added /usr/local/bin in my bash profile ahead of all paths on $PATH so
> that it would default to /usr/local/bin/python instead
> of /usr/bin/python. Then I installed with 'python tg-setup.py' that I
> downloaded from turbogears.org
>
python2.4. Also, the latest TurboGears stack should be in FE6. yum
install TurboGears:
$ tg-admin quickstart foo
Enter package name [foo]:
....
(If something's out of date with the Fedora Extras packages, please file
a bug at bugzilla.redhat.com and we'll get to work updating the stack.)
-Toshio
Dave
use CherryPy 3.0 (I think). Is it possible to just download CherryPy 3
over the CherryPy included with TG and expect everything to work?
Karl Guertin
That's the $64000 question. We're pretty sure that it'll work with
minor tweaks, but all the TG committers are busy with life or (in my
case) with docs. If you get it working, we'd appreciate you letting us
know.
fumanchu
Depends on what you mean by "minor". CP 3 is a major version change,
and is backward-incompatible in several ways. In addition, TG has
monkeypatches for some parts of CP 2 that are no longer present in CP
3. Finally, some of the good ideas of TG have been folded back into CP
3, and should probably be pruned from TG (or at least re-wrapped) at
some point.
The best resources for anyone taking this on are:
http://www.cherrypy.org/wiki/UpgradeTo30
http://www.cherrypy.org/wiki/WhatsNewIn30
Please keep in mind that we're not out of beta yet (but we're VERY
close). So don't bet the farm on any CP 3 syntax or features. Just
today, I'm finishing a rewrite of InternalRedirect, a rather sweeping
architectural feature (in order to make hooks safer).
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
Lee McFadden
At the moment we are aiming to move to CP3 in TurboGears 1.1.
--
Lee McFadden
blog: http://www.splee.co.uk
work: http://fireflisystems.com