Re: [Zope3-dev] z3c.formjs-0.2 and z3c.formjsdemo-0.2 released!
Hi Paul, Hey, very smooth. Congratulations. I've committed a change to buildout.cfg removing z3c.form* develop eggs which kinda spoilt the buildout. Best regards, Darryl Cousins ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.formjs-0.2 and z3c.formjsdemo-0.2 released!
The 0.2 versions of z3c.formjs and z3c.formjsdemo have just been released! (for the blog version of this mail, see http://beta.carduner.net/wordpress/?p=20) For those who have not been following the development, z3c.formjs is a package that extends z3c.form (written by Stephan Richter and Roger Ineichen), adding JavaScript and AJAX functionality. More specifically, it allows you to control JavaScript and AJAX from within a presentation component like a form based view class. Alternatively ala Stephan Richter, This package is designed to provide a Python API to common Javascript features for forms written with the "z3c.form*" packages. While the reference backend-implementation is for the JQuery library, any other Javascript library can be hooked into the Python API. Here's what's new in the 0.2 release, taken straight from CHANGES.txt: z3c.formjs - Version 0.2.0 (7/18/2007) * Feature: Registration of public AJAX server calls via a simple decorator. The calls are made available via a special ajax view on the original view. * Feature: Allow registering of JS subscriptions via a decorator within the presentation component. * Feature: Added a new CSS selector. * Feature: Implementation of AJAX-driven widget value validation. * Restructure: Completely overhauled the entire API to be most easy to use and have the most minimal implementation. * Bug: The package is now 100% tested. * Feature: Implementation of AJAX request handlers in forms. z3c.formjsdemo Version 0.2.0 (7/18/2007) * Feature: The new chatroom demo implements a simple chat client in HTML and Javascript using the z3c.formjs package. * Feature: Validation demo showing off on the fly ajax field validation. * Restructure: Code updated to keep up with the changes in the API of z3c.formjs. Installation Instructions -- To checkout the demo, perform the following commands: svn co svn://svn.zope.org/repos/main/z3c.formjsdemo/tags/0.2.0 z3c.formjsdemo cd z3c.formjsdemo python2.4 bootstrap.py ./bin/buildout -Nv ./bin/demo fg The demo will then be available at http://localhost:8080. Alternatively, checkout the live demo at http://demo.carduner.net:8080/ (please no slashdot posts) Cheese Shop - Both of these packages are available on the Python Cheese Shop at * http://cheeseshop.python.org/pypi/z3c.formjs/0.2.0 and * http://cheeseshop.python.org/pypi/z3c.formjsdemo/0.2.0 Want to help? -- This is by no means a one (or two (or three ( … ) ) ) (wo)man project and I am very interested in what kinds of use cases other people have and would like to see implemented or demonstrated. I am also very interested in having other people join the fun and hack on some code. z3c.formjs is in theory JavaScript library agnostic, and I would love for that theory to be tested with a MochiKit rendering plugin or any other type of rendering plugin. So, please if you are interested, contact me at paulcarduner at gmail dot com or just make lots of noise on zope3-users, zope3-dev, or #zope3-dev and we can discuss further goals and tasks. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dealing with external dependencies
On Jul 18, 2007, at 5:24 PM, Philipp von Weitershausen wrote: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Admittedly, setuptools doesn't exactly make it easy to say "I depend on ZODB 3.8.x". Jim has proposed to add a syntax to setuptools to support this nicely but it's not there yet. So I guess we'll have to wait for that. Heads up: I've come to think that depending on major revisions/series isn't going to work. I'll say more about that in a separate thread though. Things are a bit different with external dependencies (docutils, mechanize, ClientForm, twisted, etc.), I think. They bear a higher risk of breaking stuff for us in future releases, even if they're just minor releases, because we don't control them and their developers probably don't test their stuff with our code [1]. Yes. Back in the old days, we would do vendor imports or use revision tags for the externals. This was at the monolithic zope checkout level. This was basically the equivalent of depending on a specific, well- known working version of the external package. I'm not sure what you mean here. The equivalent to what we did before is to depend on specific versions at the *application* level, by fixing a version in a application meta package or in a buildout. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. Depending on specific versions in library packages (as opposed to application packages or buildouts) is a recipe for disaster IMO. As soon as 2 packages depend on different externals, then those 2 packages won't be usable together. In the long run, it might be better to only reuse packages that offer some backward compatibility promises. Depending on a specific version will make the dependent packages less reusable. [1] This problem has bitten us over at Grok because apparently Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to actually exist anywhere and therefore confuses zc.buildout. See https://bugs.launchpad.net/grok/+bug/126742. I'm fairly sure that this has nothing to do with version numbers. I suspect instead that it has something to do with the fact that all distributions are now installed as "develop eggs" on ubuntu. The locations of these eggs is actually site-packages. This sounds very wonky to me, but Phillip Eby says it is normal. I'd be interested in following up on this offline or in a separate thread. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Problems with zope3 on windows
Steps to reproduce: 1. install python24 from python.org 2. run ez_setup.py to get easy_install 3. run c:\python24\scripts\easy_install grokproject (may need a C compiler, I used mingw) 4. make a grokproject running: c:\python24\scripts\grokproject sample 5. follow grokproject til it finish 6. try to run "zopectl fg" from ur project bin\ folder Here's the traceback when I run zopectl fg (may get messy cause copied from windows terminal...): E:\work\bgweb2>bin\zopectl.exe debug Traceback (most recent call last): File "E:\work\bgweb2\bin\zopectl-script.py", line 14, in ? zc.zope3recipes.ctl.main([ File "c:\documents and settings\jp\buildout-eggs\zc.zope3recipes-0.5.3-py2.4.egg\zc\zope3recipes\ctl.py", line 47, in main zdaemon.zdctl.main(args, None, Cmd) File "c:\documents and settings\jp\buildout-eggs\tmpurp5-h\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", line 626, in mai n File "c:\documents and settings\jp\buildout-eggs\tmpurp5-h\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", line 125, in __i nit__ File "c:\documents and settings\jp\buildout-eggs\tmpurp5-h\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", line 185, in get _status File "c:\documents and settings\jp\buildout-eggs\tmpurp5-h\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", line 165, in sen d_action AttributeError: 'module' object has no attribute 'AF_UNIX' The other errors came after I "fixed" zdctl.py, method send_action(self, action) starting at line 161 with this: try: sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) except AttributeError: # this is not unix maybe? return None I replaced os.spawnlp() with subprocess.call() near line 530 and then I got it working. -- JP On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote: João Paulo Fernandes Farias wrote: > I'm not sure if this is enough info to get stuff fixed, just wanted to > tell about my experiences so far. Reproduction steps would be helpful, as well as full tracebacks of the various exceptions. > I'm a bit surprised nobody noticed those issues so far, is windows so > unpopular in zope3 / grok developers? lol In a word: yes. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Problems with zope3 on windows
Benji York wrote: > João Paulo Fernandes Farias wrote: >> I'm not sure if this is enough info to get stuff fixed, just wanted to >> tell about my experiences so far. > > Reproduction steps would be helpful, as well as full tracebacks of the > various exceptions. Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Problems with zope3 on windows
João Paulo Fernandes Farias wrote: I'm not sure if this is enough info to get stuff fixed, just wanted to tell about my experiences so far. Reproduction steps would be helpful, as well as full tracebacks of the various exceptions. I'm a bit surprised nobody noticed those issues so far, is windows so unpopular in zope3 / grok developers? lol In a word: yes. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 needs a new documentation strategy
Luciano Ramalho wrote: On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote: Try googling for "zope 3 api documentation"... [1] Try googling for "zope 3 documentation". I did also, the result is not better. I was overly succinct. I meant to indicate that the first search result for that phrase was http://wiki.zope.org/zope3/Documentation. I can't think of a more appropriate result. If you're instead wishing for the _content_ of that page to be "better", then the search isn't the issue, but the page itself. I think everyone welcomes improvements there. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Problems with zope3 on windows
Hi! I'm starting to use zope3 + grok and I'm on windows environment. I've followed the grok tutorial on a linux machine but then started my real project on a windows machine. Then when I tried to run 'bin\zopectl fg" it just didn't work. It complained about socket.AF_UNIX on zdaemon\zdctl.py. I went there and surrounded with a try/except: return None. Then it complained about os.spawnlp() wich does not work on windows. I replaced it with subprocess.call() as python's doc suggest to and it worked fine. Then I had same os.spawnlp() problem with "zopectl debug", now on zc\zope3recipes\ctl.py, again replaced for subprocess.call(). But "zopectl debug" wasn't still working, was then when I figured near last line on my project file: parts\app\debugzope-script.py it has split the line that adds zc.zope3recipes egg to the path. I fixed this and now everything works fine. I'm not sure if this is enough info to get stuff fixed, just wanted to tell about my experiences so far. I'm a bit surprised nobody noticed those issues so far, is windows so unpopular in zope3 / grok developers? lol -- JP ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 needs a new documentation strategy
On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote: Luciano Ramalho wrote: > One of the first questions anyone needs answered when studying a new > framework is "Where is the canonical reference for the API?". Whatever is done, http://wiki.zope.org/zope3 is probably the right place for it. Wasn't someone going to get zope3.org pointed to that page? > Try googling for "zope 3 api documentation"... [1] Try googling for "zope 3 documentation". I did also, the result is not better. Like I said in another post (refering to the first result when googles for "zope 3 documentation"): On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote: Does http://wiki.zope.org/zope3/Documentation help? Not really. Before yesterday, there was no explanation about how to access apidoc (I put that in the linked page APIDocTool yesterday). The apidoc tool itself is limited. For debugging purposes, it might be useful that the search is limited to registered interfaces. But while reading about Zope 3 I wanted to check on IComponentArchitecture but the search could not find it. I had to use grep to find it and learn the path that I could use to browse to it in the apidoc: http://localhost:8099/++apidoc++/Interface/zope.component.interfaces.IComponentArchitecture/index.html And finally, the wiki Documentation page does not mention the abundant README.txt files scattered all over the source tree where the real documentation exists. Cheers, Luciano PS. BTW, I'd like to mention that besides the people who replied in the list, I got pvt replies of people saying that they feel the same way as I do about the current docs. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On Wed, 2007-07-18 at 18:50 +0200, Philipp von Weitershausen wrote: > * Would it help if the 'myzopeapp' package would not be in the top- > level MyZopeApp directory, but in a 'src' directory below MyZopeApp? > Would that make it clearer where to go? +1 > * grokproject actually also creates a "hello world" browser page. > That way there's some initial code there and people might know better > where to go in and change stuff. Would that help? Or would that be > too much unnecessary boilerplate? I don't think this is unnecessary boilerplate for many projects, but it's not universal. What is the appropriate way to 'specialize' the zopeproject recipe for different 'default' purposes, one of which would be 'hello world'? > > 2. Is this kind of setup (I mean using zopeproject) supposed to be > > used to deploy applications in production environments? > > It certainly can be used for deployment, though you'll probably want > to make some changes to the configuration files before you deploy > (rip out the administrator account, deactivate developer mode, > etc.). > Again, this is a good question that should be answered in the > zopeproject docs. If the most common configuration changes can be gathered into a 'deployment' recipe, that would also be useful, I think. - Michael R. Bernstein signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Dealing with external dependencies
Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Admittedly, setuptools doesn't exactly make it easy to say "I depend on ZODB 3.8.x". Jim has proposed to add a syntax to setuptools to support this nicely but it's not there yet. So I guess we'll have to wait for that. Things are a bit different with external dependencies (docutils, mechanize, ClientForm, twisted, etc.), I think. They bear a higher risk of breaking stuff for us in future releases, even if they're just minor releases, because we don't control them and their developers probably don't test their stuff with our code [1]. Back in the old days, we would do vendor imports or use revision tags for the externals. This was basically the equivalent of depending on a specific, well-known working version of the external package. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. [1] This problem has bitten us over at Grok because apparently Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to actually exist anywhere and therefore confuses zc.buildout. See https://bugs.launchpad.net/grok/+bug/126742. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 7/18/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: I'm not going to try to convince anyone to give it up, but I probably won't spend much energy in either promoting, maintaining and documenting it. Yay, Philipp! -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 21:13 , Dieter Maurer wrote: Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200: ... Imagine you're writing a GUI application. Without question you'd use some sort of GUI toolkit (e.g. wxPython). Would you expect you would have to hook into the the "wxPython application" as a plug-in? Isn't it more natural that you simply write your application and just use the wxPython *library* wherever necessary? Is this not the difference between a framework and a library? An application uses a framework by hooking its components into the framework. A library is used directly -- only miminal hooking and callbacks are used. I view GUI frameworks typically as plugging my application parts into the GUI (which triggers my application code) -- especially, if the UI is build by an UI-builder... Good point. In a way, we're actually doing this. For example, our WSGI application gets called by PasteDeploy whenever the WSGI server receives a request. That's how we hook into the "Paste framework". Then, we don't really do our own URL dispatching. The Zope publisher does its stuff and simply ends up calling our view code. That's how we hook into the "Zope publisher" framework. But then there are a bunch of things where *we* actually make the calls: assembling forms, calling a templating engine, etc. So, we're really doing both, using some frameworks and using some libraries. Maybe it's just a matter of where to draw the line. If some people (such as you) prefer to draw the line much closer to Zope-the- application, that's fine. I simply prefer to draw them closer to the loosely coupled libraries and frameworks. There's a reason for that. Zope-the-application is a big hindrance for using standard Python technologies such as eggs, WSGI, etc. It's not that eggs are going to solve world hunger (pun intended) and WSGI/ Paste isn't the end of the line when it comes to deployment, but betting on those and actually working towards sharing even more technology I think is the best thing we can do to grow Zope. I gave a lightning talk about this subject at EuroPython. I got several positive responses from Zope and non-Zoep folks, but the best was probably by Jacob Hallen who, if he ever has used Zope, probably wasn't a very enthusiastic Zope user. He said something along the lines of this: "It's good to hear that Zope is starting to be usable in bits and pieces, without having to buy into the whole Zope world." Now, I bet there are lots of Python developers out there who like Jacob have turned their back on Zope over the years exactly because of this buy-in. Zope 3 has now been successfully split up into separate pieces: individual libraries. I'd therefore like to propose an alternate approach to developing web applications with Zope: the library one, rather than the pluggable app one. I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. Right. This is what Martijn Faassen aptly calls the "Zope 2000" development model. And it's probably about the farthest away from working together with other Python web frameworks and toning down Zope for an easier entry. I'm not going to try to convince anyone to give it up, but I probably won't spend much energy in either promoting, maintaining and documenting it. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
> I will add this to the zopeproject docs. I wonder: > > * Would it help if the 'myzopeapp' package would not be in the top-level > MyZopeApp directory, but in a 'src' directory below MyZopeApp? Would > that make it clearer where to go? > > * grokproject actually also creates a "hello world" browser page. That > way there's some initial code there and people might know better where > to go in and change stuff. Would that help? Or would that be too much > unnecessary boilerplate? For me, second approach is more clear but even simple README.txt, located at new project's folder, with description of next steps, should be enough. >> 2. Is this kind of setup (I mean using zopeproject) supposed to be >> used to deploy applications in production environments? > > It certainly can be used for deployment, though you'll probably want to > make some changes to the configuration files before you deploy (rip out > the administrator account, deactivate developer mode, etc.). Again, this > is a good question that should be answered in the zopeproject docs. Would be nice to have this kind of description, especially that a lot of people is not familiar with Paste (I think so). For example I was looking for something like zopectl start|stop|restart. I don't know so far how to do it (I did not read Paste docs yet - do I really have to? ;) ). > This is interesting. I can reproduce this. Good to know that I'm not alone with this :) One more thing that is rather about 'death to zope instances' not zopeproject itself is that that so far it was possible and easy to have one Zope serving few different apps. With new way seems that instance is bound to application. This may be a pain if you have to pay for hosting. Usually there are serious restrictions to number of long running processes (like Zope) you may have (e.g. Webfaction hosting). -- Maciej Wisniowski ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 needs a new documentation strategy
Luciano Ramalho wrote: One of the first questions anyone needs answered when studying a new framework is "Where is the canonical reference for the API?". Whatever is done, http://wiki.zope.org/zope3 is probably the right place for it. Wasn't someone going to get zope3.org pointed to that page? Try googling for "zope 3 api documentation"... [1] Try googling for "zope 3 documentation". -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200: > ... >Imagine you're writing a GUI application. Without question you'd use >some sort of GUI toolkit (e.g. wxPython). Would you expect you would >have to hook into the the "wxPython application" as a plug-in? Isn't it >more natural that you simply write your application and just use the >wxPython *library* wherever necessary? Is this not the difference between a framework and a library? An application uses a framework by hooking its components into the framework. A library is used directly -- only miminal hooking and callbacks are used. I view GUI frameworks typically as plugging my application parts into the GUI (which triggers my application code) -- especially, if the UI is build by an UI-builder... > ... >Zope 3 has now been successfully split up into separate pieces: >individual libraries. I'd therefore like to propose an alternate >approach to developing web applications with Zope: the library one, >rather than the pluggable app one. I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.table.column.GetterColumn does not encode &<>
Hello, Seems like zc.table.column.GetterColumn does not encode the characters "&<>" to the usual &, <, >. Is that OK this way? I usually insert the result of the Formatter() with . That breaks havoc if a table cell's data contains any "&<>". Am I missing something? -- Best regards, Adam mailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 12:26 , Maciej Wisniowski wrote:
Maybe it is too fast for these questions but these are ones I had
just after trying zopeproject:
1. What should I do after creating project?
Where should I start writing my code? In one of folders created by
zopeproject or maybe I'm just supposed to create my own folders and
put them in pythonpath?
Heh, this is a *very* good question because I just realized that this
is nowhere documented clearly. I just assumed it would be obvious.
zopeproject actually creates an almost-empty package where you're
supposed to put the code for your web application. Let's say you
invoked zopeproject like this::
$ zopeproject MyZopeApp
...
Then inside the newly created 'MyZopeApp' directory,
$ cd MyZopeApp
you'll find a 'myzopeapp' package:
$ cd myzopeapp
$ ls
__init__.pyapplication.py configure.zcml
You can now add Python files to this package, register components in
configure.zcml, etc.
I will add this to the zopeproject docs. I wonder:
* Would it help if the 'myzopeapp' package would not be in the top-
level MyZopeApp directory, but in a 'src' directory below MyZopeApp?
Would that make it clearer where to go?
* grokproject actually also creates a "hello world" browser page.
That way there's some initial code there and people might know better
where to go in and change stuff. Would that help? Or would that be
too much unnecessary boilerplate?
2. Is this kind of setup (I mean using zopeproject) supposed to be
used to deploy applications in production environments?
It certainly can be used for deployment, though you'll probably want
to make some changes to the configuration files before you deploy
(rip out the administrator account, deactivate developer mode, etc.).
Again, this is a good question that should be answered in the
zopeproject docs.
3. Does this work with workingenv? While trying to install
zopeproject with active workingenv I get:
#-
--
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$ zopeproject newone
Enter user (Name of an initial administrator user): blablabla
Enter passwd (Password for the initial administrator user): blablabla
Enter eggs_dir (Location where zc.buildout will look for and place
packages) ['/home/pigletto/buildout-eggs']:
/home/pigletto/workingenvs/env1/buildout-eggs
Creating directory ./newone
Downloading zc.buildout...
Invoking zc.buildout...
Couldn't find index page for 'zope.app' (maybe misspelled?)
No local packages or download links found for zope.app
error: Could not find suitable distribution for Requirement.parse
('zope.app') (--always-copy skips system and development eggs)
This is interesting. I can reproduce this.
We got rid of the zope.app egg ages ago, which means that when run
within workingenv, buildout must be downloaded an ancient version of
some package that still depends on it. That again means buildout is
ignoring the find-links settings in buildout.cfg.
I've seen this behaviour once at the EuroPython sprint. I don't think
the person in question was using workingenv, but the symptoms were
the same. I thought it was an temporary anomaly ;), but it looks more
like a bug in zc.buildout. Or workingenv is doing something funny to
change easy_install's behaviour.
THanks for your input!
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 11:22 , Hermann Himmelbauer wrote: - Please carefully weight boilerplate code against "black magic": For newbies, the generated code should on one hand be easily understandable, which means that there is no code in it that requires deep understandings of Zope3 internals. On the other hand, black magic should be avoided, as such constructs are pitfalls later on. Have you actually taken a look at the boilerplate (application.py specifically)? It's very little IMO. I suppose it could use a few more comments, but even now I think it's pretty clear what it does. If not, we need to document it better or change it. This is why I wanted you guys to check this out. - If I understand this right, this is also a "server-centric" against "application-centric" issue. In your case, it's probably easier to get a single Zope3-based application running, but will it also be easy to instantiate a Zope3 server with multiple, different applications on it? Running multiple different applications within one process is not my goal. It's also very difficult to do due to the global state that we keep in our component registries (different apps will likely conflict). If I would want to support this at all, I would probably recommend creating two entirely separate WSGI applications which would be mounted to specific URL paths using PasteDeploy's composite-app. It is already possible, for example, to run a Zope app and a TurboGears2 app within the same server process. - Please don't forget about Grok in this approach, as the simplicity of Grok fits to a fast zope3 package setup. Perhaps a "zopeproject --grok" would be a good idea. zopeproject is heavily influenced by grokproject. In fact, I have a branch of grokproject that re-uses most of zopeproject's facilities (I have posted a message to the Grok list announcing this branch a few days ago already). I don't think we'll have to let grokproject die in favour of zopeproject. grokrpoject will simply be a small shim over zopeproject. - How much work is it to implement this and how do you estimate the timeline? Not sure whether I was being imprecise or whether you simply haven't read it all, but all of this is already implemented and fully functional. I actually want you guys to *try it out* for feedback. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
>
> Feedback
>
>
> As much as I see the library-driven approach replace the instance
> approach, I see zopeproject as the way to get started with an
> application instead of mkzopeinstance. I would like to ask everyone
> who's interested in checking it out and give feedback, both on these
> ideas and on zopeproject specifically.
Maybe it is too fast for these questions but these are ones
I had just after trying zopeproject:
1. What should I do after creating project?
Where should I start writing my code? In one of folders created by
zopeproject or
maybe I'm just supposed to create my own folders and put them in
pythonpath?
2. Is this kind of setup (I mean using zopeproject) supposed
to be used to deploy applications in production environments?
3. Does this work with workingenv? While trying to
install zopeproject with active workingenv I get:
#---
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$ zopeproject newone
Enter user (Name of an initial administrator user): blablabla
Enter passwd (Password for the initial administrator user): blablabla
Enter eggs_dir (Location where zc.buildout will look for and place
packages) ['/home/pigletto/buildout-eggs']:
/home/pigletto/workingenvs/env1/buildout-eggs
Creating directory ./newone
Downloading zc.buildout...
Invoking zc.buildout...
Couldn't find index page for 'zope.app' (maybe misspelled?)
No local packages or download links found for zope.app
error: Could not find suitable distribution for
Requirement.parse('zope.app') (--always-copy skips system and
development eggs)
While:
Installing.
Processing develop directory '/home/pigletto/workingenvs/env1/newone/.'.
An internal error occured due to a bug in either zc.buildout or in a
recipe being used:
AssertionError:
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$
#---
without workingenv this works.
--
Maciej Wisniowski
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Am Mittwoch, 18. Juli 2007 01:13 schrieb Philipp von Weitershausen: > Feedback > > > As much as I see the library-driven approach replace the instance > approach, I see zopeproject as the way to get started with an > application instead of mkzopeinstance. I would like to ask everyone > who's interested in checking it out and give feedback, both on these > ideas and on zopeproject specifically. I personally like the idea - it seems that this may lead to a faster setup of a zope-based package. I am no Zope3 expert but here are just my 2 cents: - Please carefully weight boilerplate code against "black magic": For newbies, the generated code should on one hand be easily understandable, which means that there is no code in it that requires deep understandings of Zope3 internals. On the other hand, black magic should be avoided, as such constructs are pitfalls later on. - If I understand this right, this is also a "server-centric" against "application-centric" issue. In your case, it's probably easier to get a single Zope3-based application running, but will it also be easy to instantiate a Zope3 server with multiple, different applications on it? - Please don't forget about Grok in this approach, as the simplicity of Grok fits to a fast zope3 package setup. Perhaps a "zopeproject --grok" would be a good idea. - How much work is it to implement this and how do you estimate the timeline? Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
