- Zope-Dev - Zope lists

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Philipp von Weitershausen 30 Jan '07

30 Jan '07

Martin Aspeli wrote: > I've been playing with this a bit over the past couple of days, and it's > now in a state where I understand what's going on and I feel that I may > well try to use it in a real project. It still needs a bit of work > (notably, the testrunner is struggling to run tests for things in the > Products/ directory) and lots more testing, but if you're at all > interested in this, now would be a great time to get involved. > > I've put up some documentation here: > > http://dev.plone.org/plone/browser/ploneout/trunk/README.txt > > To use it, you should just have to do this: > > $ svn co https://svn.plone.org/svn/plone/ploneout/trunk ploneout > $ cd ploneout > $ python boostrap.py > $ ./bin/buildout -v This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... > Depending on how svn.zope.org is feeling, that may take a while and it > uses a lot of space (since it does a full Zope 2 checkout). I would like > to explore options for using a different/common Zope 2 checkout and for > using a tarball instead of svn to get Zope 2.10 in the future. > > In any case, once that's all done, you can do: > > $ cd parts/instance > $ ./bin/zopectl fg gocept's Zope 3 instance recipe actually installs a script into the top-level bin directory, so you can do: $ bin/buildout ... $ bin/instance fg Where 'instance' is the name of the instance configuration section in buildout.cfg. So, if you have multiple instances, you can start them all with according scripts from 'bin'. It'd be really cool if z2c.recipe.zope2instance would do the same. To be frank, I think having to mess around in 'parts' sucks. I would even argue that app data like logs, databases, etc. shouldn't be in 'parts' either. You should be able to delete 'parts' and lose nothing (disclaimer: this is my view, not sure how "Buildout Jim" see it ;)). > This is a bonafide Zope 2 instance, but note that the products directory > is actually ploneout/products ($INSTANCE_HOME/Products is not used), > Data.fs will be placed in ploneout/parts/filestorage (so that buildout > doesn't delete it when it wipes the instance), and various eggs are in > play found inside ploneout/eggs (those downloaded automatically by > buildout) and ploneout/develop-eggs (those originally found in > ploneout/src). > > Thanks to Hanno for doing 99% of the work on all this. :) Yeah! We all owe beers to Hanno. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping!

8 36

dynamic table
by Graziella Toutoungis 30 Jan '07

30 Jan '07

Hello, I create a page template in order to showing a dynamic table, in this table i have a column and row (of chechbox) for giving the user the possibility of personalise the table by choosing his columns and rows. when the user check the rows and columns (exe: he chooses (id, title) from(id, title, phone,...,) and the rows data bettween 5 and 100). Now i have to generate a new page template whit the new table column: id, title and row from 5 to 100. I think that i should verify for every column and row if they are checked, and perhaps create a list from this column and another for the row? and i have another problem that every time the user do Next or Previous on this page, we lost the checked columns and rows. Thanks for all suggestions. G. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 1

Zope Tests: 7 OK
by Zope Tests Summarizer 30 Jan '07

30 Jan '07

Summary of messages to the zope-tests list. Period Mon Jan 29 12:00:00 2007 UTC to Tue Jan 30 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:27:57 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007146.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:29:31 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007147.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:31:01 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007148.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:32:31 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007149.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:34:01 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007150.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:35:31 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007151.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 29 21:37:01 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007152.html

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 30 Jan '07

30 Jan '07

whit wrote: > Jim Fulton wrote: >> whit wrote: >> ... >>>> Specific use cases would help to guide this. >>> the main usecase for me is the following... hanno writes a recipe for >>> plone, and I want to use that recipe as part of setting up a >>> openplans development environment (for example inside my workingenv >>> that I've been developing w/out plone). >> Does this recipe create something in particular? A Plone instance? >> A Plone software install? > (correct me if I'm wrong hanno) currently it would create a zope > instance w/ all the packages needed to create a plone instance(via the zmi.) I have written a couple of recipes that used together can get you an environment where you can create a Plone instance in the ZMI. So far there are no Plone specific recipes. The only Plone specific thing at the moment is the buildout.cfg found in ploneout. Currently there's: z2c.recipe.zope2install -- It will download either a tarball or checkout a SVN branch, put it into parts and run 'setup.py build_ext -i' on it. z2c.recipe.zope2instance -- This creates a Zope2 instance for you. You give it a path to a Zope2 version, which it will call mkzopeinstance.py from. There's a bunch of options that allow you to configure everything from various zope.conf options, multiple products directories, ... and it will create a zopectl like starter script in the buildout root bin folder that'll let you run tests from it and start/stop the instance. This recipe reuses zc.recipe.egg and is the only controversial in regard to workingenv. z2c.recipe.bundlecheckout -- You give this recipe an url and tell it which vcs system it is (defaulting to svn, with support for cvs as well) and it will checkout the url and put it into /parts. z2c.recipe.distros -- And another one which you give an url to and it will download an unpack a tarball into /parts. You can tell the recipe that the tarball has a nested structure (so it will go down one level and unpack that, this is useful for the CMF tarball for instance) or that the folder inside the tarball has a version suffix (like PluginRegistry does it for example). Hanno

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Ian Bicking 29 Jan '07

29 Jan '07

Martin Aspeli wrote: > whit wrote: > >> actually, in my current workplace, workingenv is the standard way to set >> up one's dev environment. but in the context of the previous statement, >> familar is perhaps a better word. > > I'm still not clear how widely used workingenv is? Is it "officially > endorsed" anywhere else? It steps more lightly than buildout does. It's also mostly equivalent in mechanism to virtual-python, which is used quite widely. Both use setuptools conventions more closely than buildout does. It would be nice if I could say "then you get access to all the setuptools-related management tools", except there are almost none :( But if they *did* exist you'd get access to them ;) Build stuff seems surprisingly contentious. The debate around setuptools itself has always been far more difficult than it should be; there's a lot of stop energy. So the Python community as a whole is moving very slowly on this stuff. Ian

2 2

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Ian Bicking 29 Jan '07

29 Jan '07

Jim Fulton wrote: > Ian Bicking wrote: > >> What I would *like* the distinction between workingenv and buildout to >> be is that workingenv is interactive (i.e., install with easy_install) >> and buildout is declarative (i.e., specify your environment with >> buildout.cfg). > > Well said. I was looking for a way to bring this up in the discussion. > This is a key difference. > > When you use workingenv, how to you reproduce an existing > workingenv? Is there something you can check in and later > check out to get the same workingenv? Or is this just not in > scope? Maybe it should be out of scope, but I have built something into workingenv for it. You specify a file or URL with --requirements, a text file of things to install. You can also indicate --find-links and --editable in the file, as well as refer to another requirements file. The files look like: Pylons==0.8.2 # Adds several eggs and links that aren't on PyPI: -f http://pylonshq.com/download/0.8.2/ ZPTKit SQLObject==0.7.2 Then it will install all these packages. You might then put this at http://svn.myrepo.org/svn/projects/pylons_project.txt and then create another like: -r http://svn.myrepo.org/svn/projects/pylons_project.txt -f http://svn.myrepo.org/svn/projects/project_index.html -e MyProject This would set up the basic Pylons environment, but also add an editable version of MyProject into src/, including activating the file. (Notably MyProject *should* require Pylons and the other packages, seemingly rendering the pylons_project.txt useless, but probably *shouldn't* require exactly Pylons==0.8.2 because then you'd have to break that requirement to even test if such an exacting requirement was actually true.) workingenv also saves some of these settings (like the requirements file) so you can rerun it on a directory. If the requirements file had changed you'd get the updates, or if workingenv had changed it'd rewrite its files. Ideally you'll switch things around, rerun your tests, do some development, and once you've reached a stable state push those changes back into the requirements file. Another motivation for this was to make a simple command for people to try out a new framework, like: wget http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py # You might also have several files attached to specific tutorials or # use cases: python workingenv.py \ -r http://some-framework.org/requirements.txt MyProject cd MyProject source bin/activate cd src paster create -t some_framework MyCode cd MyCode paster serve development.ini And they'd have an editable hello world at that point pretty reliably, without any system dependencies that might make the installation finicky. I had this bootstrapping idea in mind when I added --requirements, I wasn't really thinking much about deployment. It doesn't work well for things like database drivers (which are often needed for tutorials), which are often hard to install with easy_install; this is probably why I should make --site-packages default to on, and then just tell developers to use --no-site-packages to tests their requirements files. But anyway, with the goal of bootstrapping new developers without having to explain the tedious details of Python's packaging conventions, I think workingenv does reasonably well. -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org

2 1

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Jim Fulton 29 Jan '07

29 Jan '07

Ian Bicking wrote: > What I would *like* the distinction between workingenv and buildout > to be is that workingenv is interactive (i.e., install with > easy_install) and buildout is declarative (i.e., specify your > environment with buildout.cfg). Well said. I was looking for a way to bring this up in the discussion. This is a key difference. When you use workingenv, how to you reproduce an existing workingenv? Is there something you can check in and later check out to get the same workingenv? Or is this just not in scope? > They aren't *far* apart, but there's some distinctly different > mechanics. And different goals. > workingenv's techniques (which are mostly just > setuptools/easy_install's) aren't great, and I wish they were > better, but buildout's don't seem right to me either. <shrug> I'm very happy with the approach so far. I know lots of improvements can be made and I expect buildout to evolve over time and people learn from experience with it. Feedback is very welcome. A number of comments you've made have led to improvements and your *specific* comments are much appreciated. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Reinout van Rees 29 Jan '07

29 Jan '07

Martin Aspeli wrote: >> Unless Utopia really exists I think developers all have their own >> thoughts about setting up their development environment. > > Maybe. Except if we (the plone core developers) use ploneout then we are > all using the same environment, and we duplicate less work. Same reasoning I had with instancemanager, so I agree. I explicitly made it reasonable easy to set some defaults to have it fit everyone's favourite way of ordering his stuff. Instance in ~/instances/philips by default, but Jean-Paul can set it to a default of ~/Sites/philips, for instance. But even with that level of adaptability-to-individual-taste, not everyone uses it for our zest projects. Rocky not, iirc, for instance. Neither nouri. So: "it duplicates less work" and "we all would have the same environment" are great reasons, but they don't always work :-) >> Again most developers are pretty demanding about setting up a >> development environment. Here at Zest most of us are comfortable with >> instancemanager. > > That's possibly something to do with the fact that you wrote it :) > > I'm not saying it isn't great, and there's no reason why people > shouldn't use it if it works for them. But zc.buildout predates it, > seems to be adopted more and more in the Zope 3 world (including people > like grok), seems more flexible to me... and I like it. :) Well, predates it... Theoretically, yes. But in practice it was some internal zope corp tool. I only first noticed it when Jim gave a talk about the new improved egg-using version at 2006's Europython. Later that same day I gave a lightning talk about instancemanager. So at least to my viewpoint, it has the same age. http://vanrees.org/weblog/archive/2006/07/04/jim-fulton-zc-buildout http://vanrees.org/weblog/archive/2006/07/04/europython-lightning-talks > Ultimately, though, it doesn't really matter what people use. However, > at the upcoming Amsterdam sprint, I intend to ask people to do this: > > $ svn co https://svn.plone.org/svn/plone/ploneout/trunk plone3 > $ cd plone3 > $ python bootstrap.py > $ ./bin/buildout > > and they will have a Plone 3 instance to develop from. I won't be > helping anyone set up Plone in another way, simply because from previous > sprints I know that we waste an awful lot of time on something so simple > as getting people to symlinks eggs around (yipes). During Plone 3 > development, dealing with two bundles (which meant each review bundle > needed two bundles as well) that explicitly check out various eggs was a > pain in the ass as well. Something that automates this is very useful. I started instancemanager for the same reason: to do away with hour-long bughunts just because someone had an old product lying around. >From what I understand, Jean-Paul has an instancemanager configuration that builds a nice plone 3.0 instance from the normal, unmodified bundle with just a few lines of instancemanager configuration. Just keep the bundle sane and everything should be OK. Either buildout/ploneout or instancemanager can help. The goal is the same. Reinout -- Reinout van Rees r.van.rees @ zestsoftware.nl http://vanrees.org/weblog/ http://zestsoftware.nl/ "Military engineers build missiles. Civil engineers build targets."

1 0

Zope Tests: 7 OK
by Zope Tests Summarizer 29 Jan '07

29 Jan '07

Summary of messages to the zope-tests list. Period Sun Jan 28 12:00:00 2007 UTC to Mon Jan 29 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:05:38 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007139.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:07:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007140.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:08:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007141.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:10:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007142.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:11:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007143.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:13:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007144.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:14:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007145.html

1 0

RFC: Acquisition and __parent__ pointers
by Philipp von Weitershausen 28 Jan '07

28 Jan '07

This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making the widely used Acquisition API aware of Zope 3's __parent__ pointers. This will alleviate the need of using Acquisition base classes in Zope 2 for every security-sensitive object, be it persistent or just a dynamically looked up component such as a view. The goal is to enable the use of Zope 3 components in Zope 2 straight away without creating subclasses that mix in Acquisition for security's sake. See http://wiki.zope.org/zope2/AcquisitionAndParentPointers for the full proposal. Comments are appreciated. I expect little resistance to this as it pretty much doesn't change any existing semantics and just makes all of our lives much simpler. Also, if it helps, this has been blessed by Jim in discussion at the EuroPython 2006 sprint. As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text). :) -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

4 3