Re: [Zope3-dev] Broken tests since last checkout
On 2/18/07, Roger Ineichen [EMAIL PROTECTED] wrote:
Since the newest Zope3 trunk checkout,
some tests are not running. This tests are based
on a custom test layer.
Exception raised:
Traceback (most recent call last):
File D:\trunk\Zope3\src\zope\testing\doctest.py, line 1361, in __run
compileflags, 1) in test.globs
File doctest README.txt[4], line 1, in ?
manager.open('http://localhost/sampledata.html')
File D:\trunk\Zope3\src\zope\testbrowser\browser.py, line 223, in
open
self.mech_browser.open(url, data)
File D:\trunk\Zope3\src\mechanize\_mechanize.py, line 177, in open
return self._mech_open(url, data)
File D:\trunk\Zope3\src\mechanize\_mechanize.py, line 202, in
_mech_open
response = UserAgent.open(self, self.request, data)
File D:\trunk\Zope3\src\mechanize\_opener.py, line 234, in open
response = urlopen(self, req, data)
File C:\Python24\lib\urllib2.py, line 376, in _open
'_open', req)
File C:\Python24\lib\urllib2.py, line 337, in _call_chain
result = func(*args)
File D:\trunk\Zope3\src\zope\testbrowser\testing.py, line 123, in
http_open
return self.do_open(PublisherConnection, req)
File C:\Python24\lib\urllib2.py, line 993, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File D:\trunk\Zope3\src\zope\testbrowser\testing.py, line 80, in
request
self.response = self.caller(request_string, handle_errors)
File D:\trunk\Zope3\src\zope\app\testing\functional.py, line 592, in
__call__
environment)
File D:\trunk\Zope3\src\zope\app\testing\functional.py, line 625, in
chooseRequestClass
return chooseClasses(method, environment)
File D:\trunk\Zope3\src\zope\app\publication\httpfactory.py, line
33, in chooseClasses
factory = factoryRegistry.lookup(method, content_type, environment)
File
D:\trunk\Zope3\src\zope\app\publication\requestpublicationregistry.py,
line 97, in lookup
raise ConfigurationError('No registered publisher found '
ConfigurationError: No registered publisher found for (GET/)
Does anybody have any hints why the publisher is missing?
I am not getting this error when running 'python2.4 test.py' in Zope 3
trunk checkout.
How did you run this test?
Regards,
Baiju M
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Eggification and some random files/packages
Hi, How we will be installing Zope 3.4, can I do it like this: easy_install zope3 If this is the case, the zope3 package will contain few files/packages which are not separately eggified? What are the minimum files required in this zope3 package? I assume some scrips,docs etc. will be there. There are few tests which are located outside any particular package. zope.app.ftests and zope.app.tests Either we can distribute it with our huge zope.app egg or move it to some other places. What about moving those tests to zope.app.zcmlfiles ? Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Eggification and some random files/packages
I hope others will comment, but I'll make some initial high-level observations: - As I've said many times before, Zope 3 is both a library (really a collection of libraries) and an application. - For the purpose of using Zope 3 as a library, there is no need for a Zope 3 egg. There is a need for individual eggs. We also need to get the egg dependencies right. (FWIW, my near-term goal is to get to the point that we can build out our applications using the individual Zope eggs.) - For using Zope 3 as an application: o It isn't clear that anyone is interested in really caring about the Zope 3 application as previously distributed (aka ZMI or OFS). I'm not aware that anyone has come forward to champion the Zope 3 application and, more important, take leadership for the Zope 3 application. I certainly think that there should be some applications of Zope 3 that are useful and provide examples of use. o It isn't clear that an egg is really the best distribution format for Zope 3 the application, but that is really up to the people, if any, who want to lead the Zope3-as-application effort. It might still be cool if there was an application egg that basically installed some script for making instances. Jim On Feb 19, 2007, at 5:17 AM, Baiju M wrote: Hi, How we will be installing Zope 3.4, can I do it like this: easy_install zope3 If this is the case, the zope3 package will contain few files/packages which are not separately eggified? What are the minimum files required in this zope3 package? I assume some scrips,docs etc. will be there. There are few tests which are located outside any particular package. zope.app.ftests and zope.app.tests Either we can distribute it with our huge zope.app egg or move it to some other places. What about moving those tests to zope.app.zcmlfiles ? Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- 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] Eggification and some random files/packages
(Replying to myself!) Baiju M wrote: There are few tests which are located outside any particular package. zope.app.ftests and zope.app.tests Either we can distribute it with our huge zope.app egg or move it to some other places. What about moving those tests to zope.app.zcmlfiles ? When I looked at zope.app.tests, I can see that it is a deprecated package. So no need to moving anywhere. But zope.app.ftests has a test case (reusable?) Again I couldn't find any advantage for moving this too. So I will simply put it as svn:externals in zope.app egg package. May be we have to deprecate zope.app.ftests too? Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Eggification and some random files/packages
Baiju M wrote: (Replying to myself!) Baiju M wrote: There are few tests which are located outside any particular package. zope.app.ftests and zope.app.tests Either we can distribute it with our huge zope.app egg or move it to some other places. What about moving those tests to zope.app.zcmlfiles ? When I looked at zope.app.tests, I can see that it is a deprecated package. So no need to moving anywhere. But zope.app.ftests has a test case (reusable?) Again I couldn't find any advantage for moving this too. So I will simply put it as svn:externals in zope.app egg package. May be we have to deprecate zope.app.ftests too? Well, after few more looks into test cases, I am planning to move src/zope/app/ftests/test_functional.py to src/zope/app/testing/ftests.py And move src/zope/app/ftests/doctest.txt to src/zope/app/testing/doctest.txt I have done this in my checkout. Can anyone review this: http://zissue.berlios.de/z3/zope-app-testing-diff.txt I have also added a test layer for these ftests. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Buildout default behaviour
I'm testing buildout, and one thing I want is to have several cfgs, one for development, one for staging and one for production. Now, calling one of the configurations buildout.cfg would make it the default. That means that if you just run bin/bildout, it will try to install that configuration. That's fine for installing, but not for updating. If you install it with -c staging.cfg, and then without -c at all, it will try to switch to the buildut.cfg configuration, which is not what you want. Now, a clever way around this ought to be to have no buildout.cfg at all, and therefore no default, right? Nope, because if you run it then, it will create an empty buildout.cfg, and then promptly go around building it. Which has the effect that everything gets UNINSTALLED! That's not what I want as default behaviour. :-) Can we change this to complaining that buildout.cfg doesn't exist instead? -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] gocept looking for fulltime developer
Hi, we're hiring. Just in case someone isn't reading the German lists or is interested to work in Germany, gocept is hiring. The German job description is here: https://members.zope.de/Members/ctheune/softwareentwickler-m-w/ (Note that the *ideal* candidate speaks German, but we might like you anyway. If you're interested in a full-time Zope job in Germany, please send a mail with a detailed resume to [EMAIL PROTECTED]) Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Buildout default behaviour
Hi, here's the pattern that we use: - create a directory 'profiles/' in your buildout - create a file 'profiles/base.cfg' that describes all parts and their default configurations - create a file 'profiles/dev.cfg' that has the development variation and uses '[buildout] extends=base.cfg' Then we do not check in a buildout.cfg at all. We put an SVN ignore on that actually. When doing a checkout of the buildout, we run bootstrap which creates an empty buildout.cfg (and uninstalls all of the 0 parts which I don't care about). We then set the buildout.cfg to look like this: [buildout] extends = profiles/dev.cfg and run bin/buildout. This works very well for us. Christian Am Montag, den 19.02.2007, 16:32 +0100 schrieb Lennart Regebro: I'm testing buildout, and one thing I want is to have several cfgs, one for development, one for staging and one for production. Now, calling one of the configurations buildout.cfg would make it the default. That means that if you just run bin/bildout, it will try to install that configuration. That's fine for installing, but not for updating. If you install it with -c staging.cfg, and then without -c at all, it will try to switch to the buildut.cfg configuration, which is not what you want. Now, a clever way around this ought to be to have no buildout.cfg at all, and therefore no default, right? Nope, because if you run it then, it will create an empty buildout.cfg, and then promptly go around building it. Which has the effect that everything gets UNINSTALLED! That's not what I want as default behaviour. :-) Can we change this to complaining that buildout.cfg doesn't exist instead? -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Buildout default behaviour
On 2/19/07, Christian Theune [EMAIL PROTECTED] wrote: Hi, here's the pattern that we use: - create a directory 'profiles/' in your buildout - create a file 'profiles/base.cfg' that describes all parts and their default configurations - create a file 'profiles/dev.cfg' that has the development variation and uses '[buildout] extends=base.cfg' Then we do not check in a buildout.cfg at all. We put an SVN ignore on that actually. When doing a checkout of the buildout, we run bootstrap which creates an empty buildout.cfg (and uninstalls all of the 0 parts which I don't care about). We then set the buildout.cfg to look like this: [buildout] extends = profiles/dev.cfg and run bin/buildout. This works very well for us. Good idea, thanks for the hint. That gets around the problem (even though I still propose that the default behaviour change). -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
