|
Re: Python UK meeting and Django
Brandon Craig Rhodes wrote:
[snip]
> Could we move the versions into setup.py? :-) I'm sorry that I keep
> asking this, because I know there's always an answer as to why we
> don't, but I can never remember.
Why we don't is because we want to give the users the flexibility to
deviate from the versions we list. If we put them in setup.py there's no
way to override them.
If putting them in the setup.py would fix all our installation problems,
I personally could live with that personally, even though it'd annoy
quite a few Zope 3 users.
One solution to make the Zope 3 users happy is to instead create a
grok-meta package which *does* pin the versions down, but then you'd
still need to tell people to install 'grok-meta', not 'grok'. That
doesn't improve our situation compared to what we have now with
grokproject; you'd still need to remember to get grok-meta instead of grok.
Anyway, let's ignore that problem for now. We put the versions in
setup.py. Now you do 'easy_install grok'. And then what? Currently it
doesn't set up anything up that you could can just use. Should it set up
grokproject for you? Would this in turn set up a buildout?
One reason to encourage the use of grokproject right now is that dumping
all that stuff into your system site-packages is really not a good idea.
You'd have to rely on people's knowledge of tools like virtualenv.
Another feature of grokproject now on trunk is the ability to download
an "egg basket" tarball with dependency eggs. This avoids having our
installation process fail due to some random failure to download some
dependency somewhere (sourceforge, say). If we told people to
"easy_install grok", that couldn't be done (it'd need to be integrated
into setuptools first).
We want to avoid there being too many ways to do things too. Right now
grokproject sets up a buildout for you, and you work with that. I
believe buildout adds nice features we don't want to do without. If we
introduced another way to install grok, we'd need to maintain
documentation on that too, and answer questions, and such.
It's clear though that documentation doesn't work to make people not do
'easy_install grok'. grok.zope.org has multiple places where it tells
you what to do, and the grok page on pypi tells you to use grokproject
too. It's not to clear to me how severe the problem is.
And it's true that Grok isn't particularly better than Django on this.
That said, what you *can* do with Grok is things like 'easy_install
martian' and 'easy_install grokcore.component' (and zope.component and
zope.interface, etc). I understand you can't really do that with the
bits of Django. You can't do it for *all* the bits of Grok yet, but
we're very interested in supporting this.
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
On May 7, 2008, at 3:40 PM, Brandon Craig Rhodes wrote:
> Reed O'Brien < reed@...> writes:
>
>> reed:~ reedobrien$ easy_install django
>> ...
>> sigh.
>
> I'm not sure what your point is, Reed. :-) Grok is *much* worse than
> Django in this respect. If you try to easy_install django, then, as
> you've seen, you get an error. If you try instead to easy_install
> Grok, then you get the wrong versions of a hundred packages tossed
> merrily into your site-packages, because we don't bother to list
> versions in our setup.py - against all known Python convention, I
> might add. You've then wedged yourself: you can't use Grok now by
> trying to import it, but you also can no longer run "grokproject" and
> have the resulting app run, because the easy_install inside the
> buildout apparently becomes terribly confused by the wrong versions of
> things sitting in site-packages, and your Grok project will probably
> not run at all until you've gotten on #grok, asked about what to do,
> and been guided through removing everything starting with "zope" in
> your site-packages.
You can't run easy_install in a buildout, it doesn't make much sense.
I'm not sure I understand what you mean. You should just easy_install
grokproject and use that, not easy_install grok or anything else.
People do still get version conflicts though if they have installed eggs
into the system python site-packages. I really really wish that there
was an option in buildout to make it ignore site-packages. I think
I saw Jim mentioning that it's on his todo list, but we need it now.
Many people get stuck on this. Is buildout easy enough so anyone
other than Jim can add this option?
IMHO it would not be bad do support "easy_install Grok" so people that
rather work with just virtualenv could use it. It's a little bit sad
that we
have to point to repoze when people either want grok in a virtualenv
or use wsgi. I hope we can support both right out the box (I know the
latter is coming soon).
/Tim
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
On May 7, 2008, at 10:21 AM, Tim Terlegård wrote:
>
> On May 7, 2008, at 3:40 PM, Brandon Craig Rhodes wrote:
>
>> Reed O'Brien < reed@...> writes:
>>
>>> reed:~ reedobrien$ easy_install django
>>> ...
>>> sigh.
>>
>> I'm not sure what your point is, Reed. :-)
Oops was out at a bar too late. I meant to type:
easy_install djangoproject
Sorry for the confusion.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Tim Terlegård < tim.terlegard@...> writes:
> You can't run easy_install in a buildout, it doesn't make much
> sense. I'm not sure I understand what you mean. You should just
> easy_install grokproject and use that, not easy_install grok or
> anything else.
The issue is that, because so many Grok products are willing to be
easy_installed these days, many novice users simply try "easy_install
<foo>" without even looking at any documentation. I mean, look at
Reed - he just tried it with Django, whose docs don't mention
easy_install at all. :-)
And people wanting to try out Grok before have done with Grok exactly
the same thing that Reed just did with Django: ignored the fact that
the documentation says *not* to easy_install it, and tried it anyway.
With Django this at least fails cleanly. With Grok it downloads
dozens of packages, looking busy and efficient like it's accomplishing
something the user wants, then when they try to "import grok" it
(currently; this changes month to month) reports an error with a
symbol in martian.
I am happy to report that Martijn is exactly correct; the module
versions installed by "easy_install grok" no longer prevent the user
from finding out that he's supposed to use "grokproject", and when he
does, the buildout environment ignores the wrong-versioned packages in
site-packages which, while they take up space, don't prevent Grok from
then running successfully.
I have a slight guess that some novices probably expect "grokproject"
to be a script that comes with "grok", until they realize that it's
its own module rather than just being something that "comes with" the
"grok" module itself.
--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Previously Brandon Craig Rhodes wrote:
> Tim Terlegård < tim.terlegard@...> writes:
>
> > You can't run easy_install in a buildout, it doesn't make much
> > sense. I'm not sure I understand what you mean. You should just
> > easy_install grokproject and use that, not easy_install grok or
> > anything else.
>
> The issue is that, because so many Grok products are willing to be
> easy_installed these days, many novice users simply try "easy_install
> <foo>" without even looking at any documentation. I mean, look at
> Reed - he just tried it with Django, whose docs don't mention
> easy_install at all. :-)
This is true for all frameworks I think. For example if you easy_install
Pylons the only useful thing it does for you is add a pylons project
template you can use with paster.
That makes a fair amount of sense. Perhaps grok should depend on
grokproject so that installing grok automatically makes a paster
template for grok projects available.
Wichert.
--
Wichert Akkerman < wichert@...> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Hi there,
Brandon Craig Rhodes wrote:
[snip]
> I am happy to report that Martijn is exactly correct; the module
> versions installed by "easy_install grok" no longer prevent the user
> from finding out that he's supposed to use "grokproject", and when he
> does, the buildout environment ignores the wrong-versioned packages in
> site-packages which, while they take up space, don't prevent Grok from
> then running successfully.
This is good news! Thanks for trying this out.
> I have a slight guess that some novices probably expect "grokproject"
> to be a script that comes with "grok", until they realize that it's
> its own module rather than just being something that "comes with" the
> "grok" module itself.
Hm. We could add a dependency to 'grokproject' to 'grok', so that it'll
appear even if you do the wrong thing. You'd have to sit through all the
downloads again when you first run grokproject, but least you can proceed.
Are there any drawbacks to this idea? It's just covering all the bases;
I wouldn't propose that this way to install things would in any way
become official.
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Hey,
Wichert Akkerman wrote:
[snip]
> That makes a fair amount of sense. Perhaps grok should depend on
> grokproject so that installing grok automatically makes a paster
> template for grok projects available.
Heh, great minds think alike. :)
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
 Re: Python UK meeting and Django
Damn, I keep replying to the sender instead of to the list... Sorry Brandon.
All, read below:
On Wed, May 7, 2008 at 11:34 AM, Brandon Craig Rhodes
> < brandon@...> wrote:
>> Tim Terlegård < tim.terlegard@...> writes:
>>
>>> You can't run easy_install in a buildout, it doesn't make much
>>> sense. I'm not sure I understand what you mean. You should just
>>> easy_install grokproject and use that, not easy_install grok or
>>> anything else.
>>
>> The issue is that, because so many Grok products are willing to be
>> easy_installed these days, many novice users simply try "easy_install
>> <foo>" without even looking at any documentation. I mean, look at
>> Reed - he just tried it with Django, whose docs don't mention
>> easy_install at all. :-)
Then, perhaps we shouldn't put the "grok" package itself on pypi or
anywhere else reachable through it? Or maybe we should put some dummy
package that, on installation (or on attempted use) would instruct the
user to Do The Right Thing (TM).
"grokproject" could then create a buildout with the proper
> "find-links" to actually find the right grok.
>
>> [...]
>
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Hi there,
Leonardo Rochael Almeida wrote:
[snip]
> Then, perhaps we shouldn't put the "grok" package itself on pypi or
> anywhere else reachable through it? Or maybe we should put some dummy
> package that, on installation (or on attempted use) would instruct the
> user to Do The Right Thing (TM).
>
> "grokproject" could then create a buildout with the proper
> "find-links" to actually find the right grok.
Hm, sounds like it could work.
I'm -1 to this now as it'll make our release story more complicated. We
have various packages that use grok and they'd also need to put in that
find-links. Doesn't sound ideal to me...
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
On May 7, 2008, at 10:42 AM, Martijn Faassen wrote:
>> I have a slight guess that some novices probably expect "grokproject"
>> to be a script that comes with "grok", until they realize that it's
>> its own module rather than just being something that "comes with" the
>> "grok" module itself.
>
> Hm. We could add a dependency to 'grokproject' to 'grok', so that
> it'll appear even if you do the wrong thing. You'd have to sit
> through all the downloads again when you first run grokproject, but
> least you can proceed.
>
> Are there any drawbacks to this idea? It's just covering all the
> bases; I wouldn't propose that this way to install things would in
> any way become official.
I think the current method of starting a new project with grokproject
works wonderfully. Any projects I work on in grok usually end up
managed with zc.buildout.
I thin kdocumenting that one should install grokproject and NOT grok
via easy_install is enough. If people don't read enough documentation
to see that they probably won't read deep enough to understand to use
grokproject after running easy_install grok.
~ro
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
Hi All,
On Wed, May 7, 2008 at 11:57 AM, Martijn Faassen < faassen@...> wrote:
> Hi there,
>
> Leonardo Rochael Almeida wrote:
> [snip]
>>
>> Then, perhaps we shouldn't put the "grok" package itself on pypi or
>> anywhere else reachable through it? Or maybe we should put some dummy
>> package that, on installation (or on attempted use) would instruct the
>> user to Do The Right Thing (TM).
>>
>> "grokproject" could then create a buildout with the proper
>> "find-links" to actually find the right grok.
>
> Hm, sounds like it could work.
>
> I'm -1 to this now as it'll make our release story more complicated. We have
> various packages that use grok and they'd also need to put in that
> find-links. [...]
Not really... We could release all our packages to PYPI *except* for
grok. The grok shim we put there doesn't really need to be updated,
with each grok release, though perhaps it should be updated with each
grokproject release, so it depends on and pulls the right
grokproject...
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
Hi,
Am 07.05.2008 um 15:19 schrieb Martijn Faassen:
> My worry is that if you set up a fund to do marketing and
> documentation you separate it from the community too much, and
> take away from the community the responsibility of having to care
> about these topics. I'm convinced that we, as developers of the
> platform, need to care about attracting people to our platform
> (where we can call these people "users" or "developers").
In fact there is an other problem with a fund. We had a fund in the
DZUG to improve the documentation on zope.de, but we never found
someone, who wanted to do it. ;-)
So a too general fund might not work at all.
A better approach is to raise a fund for a special project, which
only can be done with a certain amount of work, which exceeds the
usual voluntary work. We do this sometimes for a publication that is
distributed on fairs like CeBIT or Systems.
http://www.zope.de/redaktion/dzug/zope-newsWe write and publish paid articles with case studies to get the whole
publication paid.
An other example is a white paper about Plone, which I made as a spin-
off product after I wrote some articles for it-magazines about Plone.
One was even paid. ;-)
http://www.zope.de/redaktion/dzug/anwendungen/plone3.pdf/viewThis feature overview was downloaded more than 1500 times in three
months. This is pure marketing not documentation. Every time someone
asks -- e.g. in xing.com -- for a cms recommendation, I can now point
him to this white paper.
Currently I am planning a white paper about zope to have all the
things that make Zope unique in one place. I calculate an amount of
40 hours to get it done. I really love to promote Zope, Plone and
Grok on a voluntary basis and I do it a lot. But not being a
programmer I will never benefit from this white paper so I am looking
for sponsors.
>
> Writing documentation also helps you think about how things can be
> done better. If something is hard to explain, it may be a what
> we're trying to explain is too inconsistent or complicated. If it's
> hard to convince people to use our stuff, that means we might need
> improve our stuff, too! Having a separate group of people do this
> may lead to a disconnect that shouldn't be there.
This is a good point. Perhaps we lack documentation because Zope is
too hard to explain. ;-)
No serious. I hope that you understand that I do not want to separate
the documentation and marketing efforts from the community. That
would be bad. All efforts paid or voluntary should be rooted in the
community.
Viele Grüße
juh
--
DZUG e.V. (Deutschsprachige Zope User Group)
http://www.zope.de _______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Hey,
Jan Ulrich Hasecke wrote:
> Am 07.05.2008 um 15:19 schrieb Martijn Faassen:
>
>> My worry is that if you set up a fund to do marketing and
>> documentation you separate it from the community too much, and take
>> away from the community the responsibility of having to care about
>> these topics. I'm convinced that we, as developers of the platform,
>> need to care about attracting people to our platform (where we can
>> call these people "users" or "developers").
>
> In fact there is an other problem with a fund. We had a fund in the DZUG
> to improve the documentation on zope.de, but we never found someone, who
> wanted to do it. ;-)
Yes, actually getting people to write things is hard in my experience as
well.
> So a too general fund might not work at all.
>
> A better approach is to raise a fund for a special project, which only
> can be done with a certain amount of work, which exceeds the usual
> voluntary work.
[snip]
That's a good idea.
[snip]
>> Writing documentation also helps you think about how things can be
>> done better. If something is hard to explain, it may be a what we're
>> trying to explain is too inconsistent or complicated. If it's hard to
>> convince people to use our stuff, that means we might need improve our
>> stuff, too! Having a separate group of people do this may lead to a
>> disconnect that shouldn't be there.
>
> This is a good point. Perhaps we lack documentation because Zope is too
> hard to explain. ;-)
>
> No serious.
Actually I consider the "Zope is hard to explain" issue as quite
serious. Some bits of Zope 2 and Zope 3 and Grok are difficult to
explain. Part of the thing Grok tries to do is to make Zope 3 easier to
explain.
> I hope that you understand that I do not want to separate
> the documentation and marketing efforts from the community. That would
> be bad. All efforts paid or voluntary should be rooted in the community.
Understood, I think you have some good suggestions here. The
project-based funding makes sense to me.
Now we only need to find the funds. :)
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
Hi Jan,
Thanks a lot for the links! Outta curiosity is the Plone 3 whitepaper
you reference below in English or German (just thought I'd ask before
downloading ;)
Thanks,
Tim
On Wed, 2008-05-07 at 19:16 +0200, Jan Ulrich Hasecke wrote:
> Hi,
>
> Am 07.05.2008 um 15:19 schrieb Martijn Faassen:
>
> > My worry is that if you set up a fund to do marketing and
> > documentation you separate it from the community too much, and
> > take away from the community the responsibility of having to care
> > about these topics. I'm convinced that we, as developers of the
> > platform, need to care about attracting people to our platform
> > (where we can call these people "users" or "developers").
>
> In fact there is an other problem with a fund. We had a fund in the
> DZUG to improve the documentation on zope.de, but we never found
> someone, who wanted to do it. ;-)
>
> So a too general fund might not work at all.
>
> A better approach is to raise a fund for a special project, which
> only can be done with a certain amount of work, which exceeds the
> usual voluntary work. We do this sometimes for a publication that is
> distributed on fairs like CeBIT or Systems.
> http://www.zope.de/redaktion/dzug/zope-news> We write and publish paid articles with case studies to get the whole
> publication paid.
>
> An other example is a white paper about Plone, which I made as a spin-
> off product after I wrote some articles for it-magazines about Plone.
> One was even paid. ;-)
> http://www.zope.de/redaktion/dzug/anwendungen/plone3.pdf/view> This feature overview was downloaded more than 1500 times in three
> months. This is pure marketing not documentation. Every time someone
> asks -- e.g. in xing.com -- for a cms recommendation, I can now point
> him to this white paper.
>
> Currently I am planning a white paper about zope to have all the
> things that make Zope unique in one place. I calculate an amount of
> 40 hours to get it done. I really love to promote Zope, Plone and
> Grok on a voluntary basis and I do it a lot. But not being a
> programmer I will never benefit from this white paper so I am looking
> for sponsors.
>
> >
> > Writing documentation also helps you think about how things can be
> > done better. If something is hard to explain, it may be a what
> > we're trying to explain is too inconsistent or complicated. If it's
> > hard to convince people to use our stuff, that means we might need
> > improve our stuff, too! Having a separate group of people do this
> > may lead to a disconnect that shouldn't be there.
>
>
> This is a good point. Perhaps we lack documentation because Zope is
> too hard to explain. ;-)
>
> No serious. I hope that you understand that I do not want to separate
> the documentation and marketing efforts from the community. That
> would be bad. All efforts paid or voluntary should be rooted in the
> community.
>
> Viele Grüße
> juh
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
|
|
Re: Python UK meeting and Django
Noah Gift wrote:
They
were successful due to brilliant marketing (kudos man), a
mostly-developed python answer to RoR, a good sense of timing and
strong community development skills.
I
agree, and if you doubt this truth, then read Four Hour Work Week.
Anyone can create their own image, and expertise in weeks, but it
requires tenacious and persistent marketing. They, or the entity,
needs to write many articles, give talks, etc. Unfortunately, often
the very smartest people suck the most at engaging in this type of
necessary behavior.
Perhaps grok is being too nice. GROK SMASH YET ANOTHER ROR RIPOFF.
</rant>
Of course a real advantage for DJango is that they are AppEngine ready.
Interestingly the Datastore is much more akin to the ZODB than it is to
an RDB.
I
have been playing with the Datastore and like it quite a bit. I would
love to see a version of Grok that just uses the Datastore as option.
I would really, really like Grok then. I know we have a "Global
Sprint" coming at the end of May, and also some people that use Grok
will be attending the Google I/O event. Anyone want to try...?
Yup, I'm game. The 1,000 file limit is pretty tough. A did a basic test
doing an install of ore.wsgiref, and ended up with 3000+ files without
including zcml.
My mini-strategy is to
* get easy_install zope.component
* get martian working
* implement custom traversal
* fork grok :) doh!
After looking at the Datastore it may yet be possible to do
object-based publishing by replacing persistence. I'll have to catch up
with you at Google I/O.
Kevin Smith
Monterey County Weekly
http://www.montereycountyweekly.com
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
I
have been playing with the Datastore and like it quite a bit. I would
love to see a version of Grok that just uses the Datastore as option.
I would really, really like Grok then. I know we have a "Global
Sprint" coming at the end of May, and also some people that use Grok
will be attending the Google I/O event. Anyone want to try...?
Yup, I'm game. The 1,000 file limit is pretty tough. A did a basic test
doing an install of ore.wsgiref, and ended up with 3000+ files without
including zcml.
My mini-strategy is to
* get easy_install zope.component
* get martian working
* implement custom traversal
* fork grok :) doh!
After looking at the Datastore it may yet be possible to do
object-based publishing by replacing persistence. I'll have to catch up
with you at Google I/O.
Great. Maybe the Grok/Zope experts can answer this question. If you had 1 month to live, and your life's goal was to make Grok work on google app engine. What would you do :) Could it work.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
Hi there,
Noah Gift wrote:
[snip]
> Yup, I'm game. The 1,000 file limit is pretty tough. A did a basic
> test doing an install of ore.wsgiref, and ended up with 3000+ files
> without including zcml.
>
> My mini-strategy is to
> * get easy_install zope.component
> * get martian working
> * implement custom traversal
> * fork grok :) doh!
>
> After looking at the Datastore it may yet be possible to do
> object-based publishing by replacing persistence. I'll have to catch
> up with you at Google I/O.
>
>
> Great. Maybe the Grok/Zope experts can answer this question. If you
> had 1 month to live, and your life's goal was to make Grok work on
> google app engine. What would you do :)
ME GROK SMASH SELF RITE NOW TO GET IT OVER WITH
> Could it work.
Well, the 1000 file limit is tough. Martian should work easily enough,
as it is plain Python (but for the zope.interface dependency, but you
will need that too). zope.component is harder, but much of the stuff has
Python implementations as well, so I'd try to get these working (the
Zope on Jython project is doing this). After this, we should be able to
establish grokcore.component.
You'd need to implement a container and model based on the app engine's
data store. This is now possible with Grok trunk (and megrok.rdb uses this).
The question is how many dependencies the Zope publishing machinery has.
If that can be made working we'd be quite far along.
Anyway, it'd be good if we were a bit further along with our
grokcore-ization. The more we push out into grokcore modules with
hopefully controlled dependencies, the easier it would be to drop one or
replace bits.
I'd aim for the intermediate goal of trying to make grokcore.component
to work on the app-engine. That should give a good starting point for
the rest.
Note that besides ore.wsgiref, there's also something Jim Fulton has
been working on, zope.publisher.paste, that could be interesting to explore.
Regards,
Martijn
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Python UK meeting and Django
On Thu, May 8, 2008 at 3:54 PM, Kevin Smith < kevin@...> wrote:
Noah Gift wrote:
They
were successful due to brilliant marketing (kudos man), a
mostly-developed python answer to RoR, a good sense of timing and
strong community development skills.
I
agree, and if you doubt this truth, then read Four Hour Work Week.
Anyone can create their own image, and expertise in weeks, but it
requires tenacious and persistent marketing. They, or the entity,
needs to write many articles, give talks, etc. Unfortunately, often
the very smartest people suck the most at engaging in this type of
necessary behavior.
Perhaps grok is being too nice. GROK SMASH YET ANOTHER ROR RIPOFF.
</rant>
Of course a real advantage for DJango is that they are AppEngine ready.
Interestingly the Datastore is much more akin to the ZODB than it is to
an RDB.
I
have been playing with the Datastore and like it quite a bit. I would
love to see a version of Grok that just uses the Datastore as option.
I would really, really like Grok then. I know we have a "Global
Sprint" coming at the end of May, and also some people that use Grok
will be attending the Google I/O event. Anyone want to try...?
Yup, I'm game. The 1,000 file limit is pretty tough. A did a basic test
doing an install of ore.wsgiref, and ended up with 3000+ files without
including zcml.
My mini-strategy is to
* get easy_install zope.component
* get martian working
* implement custom traversal
* fork grok :) doh!
After looking at the Datastore it may yet be possible to do
object-based publishing by replacing persistence. I'll have to catch up
with you at Google I/O.
fwiw, i started playing around with trying get z3 onto gae, its a hard issue, after fiddling away the proxies in zope.deferredmodule, there's still pkg_resource fixes to get just a barebones zope.publisher.paste running, and then there are issues with location.proxies.. you'll end up with a very stripped down z3, with little resemblance to the standard stack just pure object publishing, and thats not even including a templating engine, which have proxies referenced in them. and of course the 1000 file limit is tough, to work around you can try zip'd files but that kills existing zcml usage and template usage. at that point i realized i was just reinventing what the repoze guys have been doing.. and that for running a z3 like environment the repoze stack (obob publisher, transaction) is likely to be quite a bit easier to just run.
cheers,
kapil _______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
|
Re: Re: Python UK meeting and Django
On Thu, May 8, 2008 at 4:59 PM, Martijn Faassen < faassen@...> wrote:
Note that besides ore.wsgiref, there's also something Jim Fulton has been working on, zope.publisher.paste, that could be interesting to explore. fwiw.. its actually called ore.wsgiapp, and i'm keen to incorporate jim's paste work as it simplifies things quite a bit, but almost too much ;-) its basically a batteries not included, and requires building up zcml loading, debug/pdb mode, app startup stuff, which is why in a refactoring attempt i just left it as is, and decided to work on docs.
cheers,
kapil
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev
|
PGP.sig (193 bytes) 