- Zope-Dev - Zope lists

Why I dislike narrative doctests
by Marius Gedminas 25 Apr '08

25 Apr '08

Suppose I find a bug (say, zope.testing.testrunner.StartUpFailure objects make unittest.TextTestRunner cry). Being a good developer I want to start the bug fix with a unit test. Now if zope.testing used old-style isolated unit tests, I could open the tests.py (or tests/test_testrunner.py) in a text editor and start writing: class OptionsStub(object): post_mortem = False def doctest_StartUpFailure(): """Test that StartUpFailure is a proper unittest.TestCase StartUpFailure is a TestCase-lookalike that is inserted into the test suite to indicate that a failed import of a test module won't be unnoticed. >>> from zope.testing.testrunner import StartUpFailure >>> options = OptionsStub() >>> module_name = 'test_me' >>> exc_info = (ImportError, ImportError('zonkulator'), None) >>> test = StartUpFailure(options, module_name, exc_info) >>> unittest.TextTestRunner(verbosity=2).run(test) This is a regression test for http://launchpad.net/bugs/221151 """ There, I'm almost done. Now I can fix the bug and paste the correct output into the doctest. But zope.testing uses narrative doctests instead of isolated unit tests. There are 22 plain-text files that together comprise over 4500 lines of text. Now instead of mechanically opening the appropriate test module and grepping for the class/function name I have to figure out which of the txt files is the appropriate place for the new test. After that I have to figure out how to insert it into the narrative seamlessly. Or decide to create a new file---but a hundred of .txt files each 20-lines long is not a good idea, in my opinion. Suddenly I almost don't want to fix the bug any more. While I was writing this, I suddenly realised that almost all zope.testing's txt files are actually functional tests. There are nearly no unit tests there. Perhaps that's what causing me pain. I still maintain that: * adding a new unit test should be a trivial task * extending a narrative doctest is not a trivial task * the only way to solve this conflict is to explicitly separate unit tests (test_*.py) from doctest-enhanced API documentation (*.txt). Marius Gedminas -- UNIX is user friendly. It's just selective about who its friends are.

8 18

registering adapters and subscribers for string labels
by Chris Withers 25 Apr '08

25 Apr '08

Hi All, I bumped into hurry.workflow yesterday and was reminded again that we often have the need to register components against string labels. As an example, I want to register a subscriber to a particular workflow transition. Now, the hurry.workflow examples I've seen seem to revolve around a generic subscriber with a load of if-then-else logic in them - exactly the kind of stuff the component architecture is designed to avoid ;-) (not only that, it's *really* inefficient too) So, I dug up some code I wrote to get around this and thought I'd throw it out to the list. I have a feeling this should ship somewhere, but I don't know where. Any suggestions? (if you look you'll see the code is all tested with a nice little narrative doctest in actions.py and a selection of unit tests for the edge cases in the test file, should keep even Marius happy ;-) ) cheers, Chris PS: I showed Kapil this code yesterday and he asked "why screw with globals". The answer is to allow the registrations against names to be made in zcml - as you can see in the doctest. I'm open to other suggestions for this ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk """ This module contains class singletons for any actions that we want to register adapters against. >>> from actions import register,get To create a new one: >>> register('foo') 'foo' To get hold of one once it's been registered: >>> get('foo') <Action:'foo'> And why do we want to do all this? Well, so we can register adapters against string constants like workflow actions: >>> do_zcml(''' ... <adapter ... for="test_actions.SomeClass actions.foo" ... provides="test_actions.ISomething" ... factory="test_actions.SomethingAdapter" ... /> ... ''') Now we can get an adapter as follows: >>> from test_actions import SomeClass,ISomething >>> from zope.component import getMultiAdapter >>> o = SomeClass() >>> getMultiAdapter((o,get('foo')),ISomething) <SomethingAdapter for (<SomeClass instance>, <Action:'foo'>)> """ from new import classobj registry = {} class Action: def name(self): return self.__class__.__name__ def __repr__(self): return '<Action:%r>' % self.name() def get(name): return registry[name] def register(name): if not registry.has_key(name): mod_name = name.replace(' ','_') if mod_name in globals(): raise ValueError( '%r is not available for registration as an action name' % mod_name ) k = classobj(name,(Action,),{}) registry[name]=k() globals()[mod_name]=k return name from actions import get,register,Action from unittest import TestCase,TestSuite,makeSuite from zope.app import component from zope.component import provideAdapter from zope.configuration import xmlconfig from zope.interface import Interface,implements from zope.testing.doctest import DocTestSuite class SomeClass: def __repr__(self): return '<SomeClass instance>' class ISomething(Interface): pass class SomethingAdapter: implements(ISomething) def __init__(self,*args): self.args = args def __repr__(self): return '<SomethingAdapter for %s>' % repr(self.args) def do_zcml(text): xmlconfig.string((''' <configure xmlns="http://namespaces.zope.org/zope"> %s </configure> '''%text).strip(),xmlconfig.file('meta.zcml',component)) class Tests(TestCase): def test_get(self): # we test a bogus get here, a kosher one is tested # in test_register self.assertRaises(KeyError,get,'bogus') def test_register(self): name = register('foo') self.assertEqual(name,'foo') obj = get('foo') self.failUnless(isinstance(obj,Action)) self.assertEqual(obj.name(),'foo') self.assertEqual(repr(obj),"<Action:'foo'>") def test_duplicate_register(self): register('foo') obj1 = get('foo') register('foo') obj2 = get('foo') self.failUnless(obj1 is obj2) def test_adapter(self): register('foo bar') xmlconfig.string(''' <configure xmlns="http://namespaces.zope.org/zope"> <adapter for="actions.foo_bar" provides="test_actions.ISomething" factory="test_actions.SomethingAdapter" /> </configure> '''.strip(),xmlconfig.file('meta.zcml',component)) a = ISomething(get('foo bar')) self.failUnless(isinstance(a,SomethingAdapter)) self.assertEqual(len(a.args),1) self.failUnless(a.args[0] is get('foo bar')) def test_register_bad(self): self.assertRaises(ValueError,register,'Action') self.assertRaises(ValueError,register,'get') self.assertRaises(ValueError,register,'register') self.assertRaises(ValueError,register,'registry') def test_suite(): suite = TestSuite() suite.addTest(makeSuite(Tests)) suite.addTest(DocTestSuite('actions', globs={'do_zcml':do_zcml})) return suite

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 25 Apr '08

25 Apr '08

Summary of messages to the zope-tests list. Period Thu Apr 24 11:00:00 2008 UTC to Fri Apr 25 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Apr 24 21:03:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009455.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:05:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009456.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:06:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009457.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:08:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009458.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:09:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009459.html

1 0

paver and buildout
by Kevin Dangoor 24 Apr '08

24 Apr '08

Hi, So, I saw Martijn's "paver: buildout is utterly doomed" message on Tuesday, but I haven't had a chance to respond to it until now. As Kent points out immediately following, I plan to use zc.buildout's machinery. I actively use zc.buildout now, and I'm looking forward to getting my buildout merged into my pavement.py. I totally agree with Martijn that buildout needs a better website and I'm glad to see that Baiju is going forward with that. Ultimately, though, I think that people will choose to use buildout alone or paver+buildout (or maybe paver+virtualenv, depending on their tastes) completely based on what fits their brains better. I emailed a fair bit with Zed Shaw about his Vellum tool. He adamantly opposes having his builds defined in a full-blown language (ie Python), whereas for my needs I really want to define my builds in Python. But I want it to be easier to do than what you get with the Python standard library. People who prefer to keep there build information in a "data" format will no doubt stick with buildout. I have no problem with that. My goal is just to share the workload with other people who have similar build and deployment problems to the ones I have. Kevin

2 1

paver: buildout is utterly doomed
by Martijn Faassen 24 Apr '08

24 Apr '08

Hi there, I just found out about this site: http://www.blueskyonmars.com/projects/paver/ I know that the author has used buildout in the past. He apparently decided to roll his own. I have no idea what the technical qualities of paver are. To get your attention, let me spell out a strongly worded and opinionated message nonetheless: zc.buildout is toast. It's on the way out now. Paver is going to compete it away and buildout is doomed to be a niche project only used by weird zope people. That's strongly worded. I'll admit it's drastically overstated. It's based on virtually no technical information! But that's exactly how many programmers will judge the projects: on community aspects, and not primarily technical. Paver has this in its favor: * Paver actually has a nice website that speaks to Python programmers of simplicity. zc.buildout has cheeseshop page with a lot of doctest documentation people have said was hard to understand. (including the author of paver!) * the author is well connected in the Python community. I'd say TurboGears and Pylons people are likely to go for Paver. * it's *already* showing up on programmer's sites like programming.reddit.com, where I just found it. Nobody bothers to link to buildout, as there's no easily digestable message about it available. So, I fear very much that this, or some other alternative, will wash away the undoubtedly more feature-rich and technically robust zc.buildout, if buildout doesn't present itself better. Without better presentation, fast, buildout is doomed to be a Zope-specific thing forever. You Can Save Buildout! So, who is up to make a nice clean looking website and a few tutorials for buildout? It needs a website. Buildout has been around for a few years without a proper website already, Paver for 5 minutes and it's got one. I'm not going to do it, but someone should. Just to be sure, I certainly *won't* be doing this. Jim won't either, and I don't expect it from him. Let him write great code, not make websites. So don't sit back and hope someone else will do it, as they won't. If nobody else can bother to step up, Paver probably deserves to win. If you're intereested, I think we already have a nice buildout for deploying grok.zope.org that can probably be adapted. The repoze people have a nice site too, so you could go ask there. Alternatively we start to figure out how to convert our buildouts to Paver. :) Regards, Martijn

8 28

Zope 3.4 available as packages based on setuptools tarballs
by Brian Sutherland 24 Apr '08

24 Apr '08

I'd like to announce that the SchoolTool project has finished packaging a large proportion of the Zope 3 stack as separate Debian packages based on the setuptools tarballs from the KGS. The current development version of schooltool runs against this stack which includes most Zope 3.4 packages and ZODB 3.8. Many thanks to Ignas Mikalajunas did most of the work in preparing and testing the many separate packages in the zope namespace. Currently we are using launchpad's PPA system as a place to organize this development: https://launchpad.net/~schooltool-owners/+archive deb http://ppa.launchpad.net/schooltool-owners/ubuntu gutsy main deb-src http://ppa.launchpad.net/schooltool-owners/ubuntu gutsy main SchoolTool decided to go down this route as the current Zope 3 release and packaging looks to be on hold, with no end in sight. I'm announcing this in the hope that these packages will be useful to others. -- Brian Sutherland

6 8

zc.authorizedotnet needs a new key
by Kevin Dangoor 24 Apr '08

24 Apr '08

authorize.net has changed their CA for test.authorize.net and attempts to connect there with zc.authorizedotnet currently fail. The key that's needed is at the end of this message. Thanks! Kevin -----BEGIN CERTIFICATE----- MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTA1 MjUxNjA5NDBaFw0xOTA1MjUxNjM5NDBaMIHDMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5j b3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBF bnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUg U2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGdMA0GCSqGSIb3DQEBAQUA A4GLADCBhwKBgQDNKIM0VBuJ8w+vN5Ex/68xYMmo6LIQaO2f55M28Qpku0f1BBc/ I0dNxScZgSYMVHINiC3ZH5oSn7yzcdOAGT9HZnuMNSjSuQrfJNqc1lB5gXpa0zf3 wkrYKZImZNHkmGw6AIr1NJtl+O3jEP/9uElY3KDegjlrgbEWGWG5VLbmQwIBA6OC AdcwggHTMBEGCWCGSAGG+EIBAQQEAwIABzCCARkGA1UdHwSCARAwggEMMIHeoIHb oIHYpIHVMIHSMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5 BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1p dHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1pdGVk MTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCmgJ6AlhiNodHRwOi8vd3d3LmVu dHJ1c3QubmV0L0NSTC9uZXQxLmNybDArBgNVHRAEJDAigA8xOTk5MDUyNTE2MDk0 MFqBDzIwMTkwNTI1MTYwOTQwWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8Bdi E1U9s/8KAGv7UISX8+1i0BowHQYDVR0OBBYEFPAXYhNVPbP/CgBr+1CEl/PtYtAa MAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJKoZI hvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7Rw7/JXyNEwr75Ji174z4xRAN 95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9n9cd 2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI= -----END CERTIFICATE-----

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 24 Apr '08

24 Apr '08

Summary of messages to the zope-tests list. Period Wed Apr 23 11:00:00 2008 UTC to Thu Apr 24 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Apr 23 21:00:36 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009450.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 23 21:02:07 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009451.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 23 21:03:37 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009452.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 23 21:05:07 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009453.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 23 21:06:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009454.html

1 0

Let's fix the damned website
by Martin Aspeli 24 Apr '08

24 Apr '08

Hi all, The rumours are true. :) An effort has been going on for a while to improve the zope.org experience and thereby help make Zope more accessible to new users. I've helped co-ordinate it, but the project has been sanctioned by the Zope Foundation and driven by people like Martijn, Philipp, Wichert and others. Given Martijn's excellent blog post today (http://faassen.n--tree.net/blog/view/weblog/2008/04/05/0) and recent progress we've made, I thought it timely to open up and ask for your help. Here's what we have achieved so far: - A great design by Oliver Ruhm, paid for by Lovely Systems - A Plone 3 site hosted by Lovely Systems - A skin for this site by Denis Mishunoff - A skeleton content structure - A plan for going forward Now we need people to help contribute content, review the content that's already there and tie up a few loose ends. You can see current state of play here: http://zode01.lovelysystems.com. The original design mockups from Oliver are here: http://woimmer.com/presenter/zope.org/1.html We have agreed a plan going forward with the Zope Foundation. Basically, we want to move the current zope.org off into a separate domain, e.g. old.zope.org. We explicitly do not want to port existing content from zope.org wholesale, because (a) most of it's out of date and (b) this would be a huge effort. We'll need to provide some aliases for downloads that people (and buildouts) expect to find on zope.org, but this can be managed using Plone's RedirectionTool. We also want to start small. Some things, like planet.zope.org, wiki.zope.org and foundation.zope.org stay where they are for now. Existing documentation should be ported over manually, and subject to quality and relevancy review in the process. We want to tackle the external face of Zope first. Membership of the site will be by invitation (i.e. ask me and I'll give you an account), for content authors only. We don't want to allow arbitrary "home folders" - at least not just yet. Again, some things probably need to be moved over, but there is too much cruft on the old zope.org to move it wholesale. There has been a lot of discussion around the "message" we want to send. The current zope.org is quite confusing to people who are not familiar with the intricate history of Zope. In short, the message we want to project is: - Zope is an established, mature, "enterprise ready" project - If you don't know where to start, start with Grok (note that Grok has its own website, which we link to when relevant) - There is a common framework that unites Zope 2, Zope 3 (the app server) and Grok. We often call this "Zope 3" internally, but for the purposes of explanation, we will try to refer to the core "web application" libraries as the "Zope Libaries". - We want to frame the ZODB as something that can be used without Zope as well as an integral part of Zope To that end, the website is divided up into sections: - "Home" gives a quick overview and tries to get people excited - "Get" gives download instructions for the impatient - "Taste" whets the reader's appetite with some exciting code examples that explain how Zope is different - "Projects" gives an explanation of how the different Zope projects fit together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a subfolder that contains a standard structure: A front page that explains the project in more detail, "Get" (downloads), "Taste" (as above, but for a particular project) and "Learn". The "Learn" section should contain relevant, up-to-date documentation. - "Community" gives some details about how to join the Zope community - "Foundation" links to the Foundation site for now. If the Foundation website maintainers want to move into this site in the future, they are of course more than welcome to. Now, you'll notice that a lot of content is missing! This is where we need volunteers. o Critical reviewer -- I would like someone to review the text on the site from time to time and offer feedback on clarity, style, consistency and message. This person may either act as editor and change things on the fly, or just ask the relevant author to change something. Ideally, this is someone with an opinion on "Zope" as a whole and its place in the world. Jan Ulrich Hasecke has volunteered for this. I think we may need two or three people for this role, though. o "Get" section content champion -- needs to complete this section, writing about grokproject, zopeproject and probably a manual/source install. Needs to write clear instructions that work on all target platforms. We can split this section into sub-pages if need be. o "Taste" section champion -- needs to complete this section with some "tasty" code examples that get people excited about Zope. They don't have to be 100% complete applications; rather, they should show what sets Zope apart. A developer should be able to read this and think "I could get with this". I think we can maybe adopt something from the Appetizers section on worldcookery.com, or invent new examples. They could use Grok or plain Zope 3. This probably requires something with a strong technical background. I'd love for this to be Philipp, since he always does well with this kind of thing in presentations and training, though I'm not sure how much time he'll have. o "Community" section champion -- needs to provide some details about the Zope mailing lists/forums and chatroom. Perhaps include etiquette as well. This can probably be cribbed from plone.org/support. Then, we need a champion for each of the sub-projects. These are: - Zope 3 and the "Zope Libraries" -- this is the most important one in the short term! - Zope 2 - CMF - ZODB Grok has its own home page, though I think we should keep referring to it where it makes sense. Please reply to this thread if you are interested in helping out! I know various people have expressed an interest in the past. I hope they'll reconfirm their commitment now. Hopefully, we can get the content completed in a few weeks and then begin the move to making this the thing that people see when they hit zope.org. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

13 34

Re: [Zope.org Redux] Re: [Zope-dev] Let's fix the damned website
by Philipp von Weitershausen 23 Apr '08

23 Apr '08

On 21 Apr 2008, at 11:53 , Martin Aspeli wrote: >>> - "Projects" gives an explanation of how the different Zope >>> projects fit >>> together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a >>> subfolder >>> that contains a standard structure: A front page that explains the >>> project >>> in more detail, "Get" (downloads), "Taste" (as above, but for a >>> particular >>> project) and "Learn". The "Learn" section should contain relevant, >>> up-to-date documentation. >> >> No! >> >> Each project should have it's own site. Like Grok has today. The >> Projects page which explains what they are and how they fit together >> is fine, but the different subparts will necessarily have to be >> maintained by slightly different people with slightly different >> requirements. >> >> We can set up rules so that both zope.org/Projects/grok and >> grok.zope.org point to the same physical place, but it is extremely >> important that we do not, once again, try to make a monolithic >> zope.org. >> >> Microsites, microsites, microsites! > > Does it really matter whether a microsite lives in > zope.org/projects/zodb or zodb.zope.org? > > If you look at the projects now, they each have a common set of > sections - download, examples, documentation - and will be allowed to > evolve independently. They also have the option of having some > specific branding (logo, tag-line etc) as required. > > If anyone steps up and wants to maintain a separate site for one of > the projects, then all the better. However, it is hard enough to get > contributors as-is, so I'm loth to do anything that increases the > maintenance or setup burden in any way until we have at least the > basics in place. I agree with Martin. We need to stop the balkanization of Zope-the- brand. Yes, we have many individual projects, but we need a coherent image to the outside world. Microsites was a good idea to get foundation site and the Grok site up and running *before* tackling zope.org, but in the long run, we need coherence. Also, to be honest, I don't find the design of the new Grok website very attractive. And the foundation site is simple enough to be folded back into the main site.

3 2