Re: [Zope3-dev] rdb: Disappearing Connection redux
On Mon, Feb 13, 2006 at 05:03:55PM +0100, Jan-Wijbrand Kolman wrote: > Brian Sutherland wrote: > > On Thu, Feb 09, 2006 at 11:54:18AM +0100, Jan-Wijbrand Kolman wrote: > > > >>I add this implementation of isConnected to the mysqldbda in my setup > >>(Zope-2.9 + Five + sqlos, mysql 4.1.12) too, and things *seem* to have > >>improved. But not completely, every now and then I get the gone away > >>errors again. > > > > Make sure you have a sqlos revision after 22260, as before that sqlos was > > caching connections (even ones where the server has gone away). > > Aha! Right! Now I understand. Thanks for the hint! > > Now I only have to wait 8 hours to see if it works ;) Did it work? By the way, I had two problems reported about this fix, incredible memory usage and incredible slowness. 23429 should go some way to fix these issues. > > > kind regards, > jw > > -- > Jan-Wijbrand Kolman > [EMAIL PROTECTED] > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > > -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] rdb: Disappearing Connection redux
On Tue, Feb 21, 2006 at 04:36:26PM +0100, Jan-Wijbrand Kolman wrote: > Yes, it works, no more 'server gone away' errors! great! > I'll keep an eye on memory usage. Note though, that the application I'm > using sqlos for is completely read-only. I thought to understand the > memory usage issue was related to creating lots of records through > sqlos, right? Indeed, though the exact cause is not known. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Failure building zope tarball from trunk
Hi, I just started building the zope trunk tarball every night again, here is a failure I don't have time to debug right now. INFO: = running: zpkg -v SVN -caC releases/Zope.cfg Zope = ERROR: docutils ../src/docutils ERROR: pytz ../src/pytz ERROR: zodbcode ../src/zodbcode ERROR: zope ../src/zope ERROR: zope.* ../src/zope/ ERROR: ClientCookie../src/ClientCookie ERROR: mechanize ../src/mechanize ERROR: pullparser ../src/pullparser.py ERROR: ClientForm ../src/ClientForm.py ERROR: buddydemo ../src/buddydemo ERROR: z3checkins ../src/z3checkins ERROR: BTrees ../src/BTrees ERROR: persistent ../src/persistent ERROR: transaction ../src/transaction ERROR: ThreadedAsync ../src/ThreadedAsync ERROR: ZEO ../src/ZEO ERROR: ZODB../src/ZODB ERROR: RestrictedPython ../src/RestrictedPython ERROR: ZConfig ../src/ZConfig ERROR: zdaemon ../src/zdaemon ERROR: Zope-win ../releases/Zope-win ERROR: Zope ../releases/Zope ERROR: Zope-src ../releases/Zope ERROR: ZopeInterface../releases/ZopeInterface ERROR: ZopeTestbrowser ../releases/ZopeTestbrowser ERROR: Workflow ../releases/Workflow ERROR: ZPT ../releases/ZPT ERROR: file:///home/jinty/src/zpkgtools/ZConfig ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/tests ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/matcher.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/url.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/datatypes.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/schema.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/__init__.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/cmdline.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/substitution.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/components ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/scripts ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/cfgparser.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/info.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-Yh0At9/ZConfig/loader.py ERROR: file:///home/jinty/src/zpkgtools/zpkgsetup ERROR: file:///home/jinty/releases/Zope3/releases/Zope ERROR: file:///tmp/zpkg-Uk3L-K/loader-h1IdgZ/Zope/ZopePublicLicense.txt ERROR: file:///tmp/zpkg-Uk3L-K/loader-h1IdgZ/Zope/test.py ERROR: file:///tmp/zpkg-Uk3L-K/loader-h1IdgZ/Zope/LICENSES.txt ERROR: file:///tmp/zpkg-Uk3L-K/loader-h1IdgZ/Zope/README.txt ERROR: file:///home/jinty/releases/Zope3/src/zope/testing ERROR: file:///home/jinty/releases/Zope3/src/zope/app/mail ERROR: file:///home/jinty/releases/Zope3/src/zope/interface ERROR: file:///home/jinty/releases/Zope3/src/zope/app/server ERROR: file:///home/jinty/releases/Zope3/src/zope/app ERROR: 'adapter' doesn't match any files in ERROR: (in /home/jinty/releases/Zope3/src/zope/app/PACKAGE.cfg) ERROR: -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Failure building zope tarball from trunk
On Thu, Mar 09, 2006 at 08:52:28PM +0100, Brian Sutherland wrote: > Hi, > > I just started building the zope trunk tarball every night again, here is > a failure I don't have time to debug right now. Never mind, I got it, but now am completely stumped by this failure. It seems to occur when running bin/zopetest from an instance, but not when testing a checkout. INFO: = running: cd tst && bin/zopetest = ERROR: Running unit tests: ERROR: ERROR: ERROR: Failure in test /home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt ERROR: Failed doctest test for testrunner-coverage.txt ERROR: File "/home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt", line 0 ERROR: ERROR: -- ERROR: File "/home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt", line 20, in testrunner-coverage.txt ERROR: Failed example: ERROR: testrunner.run(defaults) ERROR: Expected: ERROR: Running unit tests: ERROR: Ran 192 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer1 tests: ERROR: Set up samplelayers.Layer1 in N.NNN seconds. ERROR: Ran 9 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer11 tests: ERROR: Set up samplelayers.Layer11 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer111 tests: ERROR: Set up samplelayers.Layerx in N.NNN seconds. ERROR: Set up samplelayers.Layer111 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer112 tests: ERROR: Tear down samplelayers.Layer111 in N.NNN seconds. ERROR: Set up samplelayers.Layer112 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer12 tests: ERROR: Tear down samplelayers.Layer112 in N.NNN seconds. ERROR: Tear down samplelayers.Layerx in N.NNN seconds. ERROR: Tear down samplelayers.Layer11 in N.NNN seconds. ERROR: Set up samplelayers.Layer12 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer121 tests: ERROR: Set up samplelayers.Layer121 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer122 tests: ERROR: Tear down samplelayers.Layer121 in N.NNN seconds. ERROR: Set up samplelayers.Layer122 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Tearing down left over layers: ERROR: Tear down samplelayers.Layer122 in N.NNN seconds. ERROR: Tear down samplelayers.Layer12 in N.NNN seconds. ERROR: Tear down samplelayers.Layer1 in N.NNN seconds. ERROR: Total: 405 tests, 0 failures, 0 errors ERROR: lines cov% module (path) ERROR: testrunner-ex/sample1/sample11/sampletests.py) ERROR: testrunner-ex/sample1/sample13/sampletests.py) ERROR: testrunner-ex/sample1/sampletests/test1.py) ERROR: testrunner-ex/sample1/sampletests/test11.py) ERROR: testrunner-ex/sample1/sampletests/test111.py) ERROR: testrunner-ex/sample1/sampletests/test112.py) ERROR: testrunner-ex/sample1/sampletests/test12.py) ERROR: testrunner-ex/sample1/sampletests/test121.py) ERROR: testrunner-ex/sample1/sampletests/test122.py) ERROR: testrunner-ex/sample1/sampletests/test_one.py) ERROR: testrunner-ex/sample1/sampletestsf.py) ERROR: testrunner-ex/sample2/sample21/sampletests.py) ERROR: testrunner-ex/sample2/sampletests/test_1.py) ERROR: testrunner-ex/sample2/sampletests/testone.py) ERROR: testrunner-ex/sample3/sampletests.py) ERROR: testrunner-ex/samplelayers.py) ERROR: testrunner-ex/sampletests/test1.py) ERROR: testrunner-ex/sampletests/test11.py) ERROR: testrunner-ex/sampletests/test111.py) ERROR: testrunner-ex/sampletests/test112.py) ERROR: testrunner-ex/sampletests/test12.py) ERROR: testrunner-ex/sampletests/test121.py) ERROR: testrunner-ex/sampletests/test122.py) ERROR: testrunner-ex/sampletests/test_one.py) ERROR: testrunner-ex/sampletestsf.py) ERROR: False ERROR: Got: ERROR: Running unit tests: ERROR: Ran 192 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer1 tests: ERROR: Set up samplelayers.Layer1 in N.NNN seconds. ERROR: Ran 9 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer11 tests: ERROR: Set up samplelayers.Layer11 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer111 tests: ERROR: Set up samplelayers.Layerx in N.NNN seconds. ERROR: Set up samplelayers.Layer111 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. ERROR: Running samplelayers.Layer112 tests: ERROR: Tear down samplelayers.Layer111 in N.NNN seconds. ERROR: Set up samplelayers.Layer112 in N.NNN seconds. ERROR: Ran 34 tests with 0 failures
Re: [Zope3-dev] Re: [Zope3-Users] PsycopgDA problem
On Thu, Mar 30, 2006 at 04:22:50PM +0400, Dmitry Vasiliev wrote: > Ok, I'll try to synchronize all my ideas about 'zope.app.rdb' with Stuart for > a > proposal. Just a random thought, so don't shoot me if it's a bad one. Perhaps it can be moved out of zope.app at the same time? -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.rdb bug?
On Mon, Apr 17, 2006 at 09:27:07AM -0500, Jeff Rush wrote:
> > Specifically, we're using the connection in a
> > non-persistent shopping cart object. Upon initialization the cart object
> > retrieves the connection from a persistent parent in the context in which
> > the cart is initialized. In this way, different shopping cart items can be
> > stored in different databases depending upon the container. The parent is
> > essentially a copy of ISQLScript.
>
> I copied SQLScript as well. Be sure that on each SQL operation you re-fetch
> the connection object using the connection name. Do not hold on to the
> connection object itself, as it may change during system re-configuration.
>
> Here is my calling method:
>
> def invoke_SQL(self, query):
>
> cache = getCacheForObject(self)
> location = getLocationForCache(self)
> if cache and location:
> _marker = object()
> result = cache.query(location, {'query': query}, default=_marker)
> if result is not _marker:
> return result
>
> try:
> connection = zapi.getUtility(IZopeDatabaseAdapter,
> self.connection_name)()
> except KeyError:
> raise AttributeError, (
> "The database connection '%s' cannot be found." % (
> self.connection_name))
>
> result = queryForResults(connection, query)
> if cache and location:
> cache.set(result, location, {'query': query})
> return result
>
> Notice the zapi.getUtility() call to re-fetch each time.
At one point in sqlos development we were re-fetching the connection
every time to get local utilities working. That turned out to have a
noticeable performance penalty, i.e. people noticed and started to
complain;)
So these days we have a per thread cache that is cleaned out before
traversing a site and at the end of every request.
--
Brian Sutherland
Metropolis - "it's the first movie with a robot. And she's a woman.
And she's EVIL!!"
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Patch for testbrowser.py
On Fri, Apr 21, 2006 at 12:17:37AM +0200, Philipp von Weitershausen wrote:
> Daniel Nouri wrote:
> > This patch adds 'Set-Cache' headers to the headers that are forwarded to
> > PublisherResponse. Before, these headers would be suppressed.
> >
> >
> > Index: testbrowser.py
> > ===
> > --- testbrowser.py (revision 66810)
> > +++ testbrowser.py (working copy)
> > @@ -35,6 +35,7 @@
> > headers.sort()
> > headers.insert(0, ('Status', "%s %s" % (status, reason)))
> > headers = '\r\n'.join('%s: %s' % h for h in headers)
> > +headers += '\r\n' + '\r\n'.join(real_response._cookie_list())
> > content = real_response.body
> > return testing.PublisherResponse(content, headers, status, reason)
> >
>
> Brian,
>
> since you added Five.testbrowser, perhaps you can say something about
> this patch and, if you think it's sound, apply it to 1.4 and the trunk?
Thanks for kicking me on this, I've been meaning to reply a for a while.
I think the best principle for the testbrowser in Five would be to keep
it as close to the Zope3 one as possible. As we would probably want to
merge the two if Zope2 uses the Zope3 publisher.
To be honest I am not enough into the zen of publishers to know the
answer but I don't see any analogue in the Zope3 testbrowser. I'm CC'ing
Z3-dev to see if anyone there knows better.
--
Brian Sutherland
Metropolis - "it's the first movie with a robot. And she's a woman.
And she's EVIL!!"
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
On Fri, Apr 21, 2006 at 01:03:58AM +0200, [EMAIL PROTECTED] wrote: > Hi Philipp > > > > That confuses me even more. I *am* proposing changes to the > > > browser:page directive... > > > > Hmm, never mind. I think I understand what you mean. You'd > > like to see new directives, instead of changing the old ones. Right? > > Yes, I think it's very important to bring a little stability to the > Zope3 framework rather then change every release such fundamental > parts like directives. FWIW, +1 on not changing the old directives. and +1 on introducing less magical directives and, eventually, deprecating and removing the old magical directives. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" damm, I really need a new quote... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] What's up with the licensing of zc.* packages?
Hi, I'm trying to get Debian packages of SchoolTool 2006 built. Since SchoolTool depends on some zc.* eggs, I'll be making packages of those as well. But, right now I'm stuck on the licensing issues, namely: * None of the zc.* packages I saw had the ZPL license text included (Is it ok if I add it?) * Some of the packages appear to be licensed under the Zope Visible Source License (ZVSL), which google tells me is confidential! "You agree to treat the Zope Visible Source Software as confidential to Zope Corporation" http://cvs.zope.org/Packages/SFTPGateway/doc/LICENSE.txt?rev=1.2 I assume this is just an oversight, should I change these headers? By package, this is: zc.i18n no license text ZVSL - http://svn.zope.org/zc.i18n/trunk/src/zc/i18n/date.py?rev=67763&view=markup zc.table no license text zc.catalog no license text, ZVSL - http://svn.zope.org/zc.catalog/trunk/src/zc/catalog/i18n.py?rev=41275&view=markup zc.datetimewidget no license text -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What's up with the licensing of zc.* packages?
On Mon, May 29, 2006 at 10:53:29AM -0400, Benji York wrote: > Brian Sutherland wrote: > > * Some of the packages appear to be licensed under the Zope Visible > > Source License (ZVSL) > [snip] > > I assume this is just an oversight > > It was, I've fixed the two you mention below. If you find any others > with the ZVSL header, let me (or the list) know. Any files that have no > license text you can add a ZPL header. Thanks Benji, I did that, added the ZPL text (from the Zope3 trunk) and re-released everything I needed. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zc.resourcelibrary/trunk/ A basic makefile, the ZPL and copyright headers.
On Wed, Jun 14, 2006 at 10:23:30PM -0400, Benji York wrote: > Brian Sutherland wrote: > > Log message for revision 68639: > > A basic makefile, the ZPL and copyright headers. > > Is there consensus about adding makefiles like this (diff below)? I > personally don't like the idea, but I wanted to bring it up to the list. > > I don't like them for a couple of reasons. First, they're make files; > that's an automatic strike :). Second, they're not useful > cross-platform; if what they're doing is important, then they should be > Python scripts, if not, then they shouldn't exist. Third, /I/ don't > value what they're doing for me. > > Other opinions? Firstly, being the one that added these, i'll take them out/replace them according to the consensus. But here's my objective: The reason I put them there in the first place is to nudge committers to create both the tarball and egg (for perhaps more than one python version) when creating a new release. The makefiles are not required and are trivially replacable by whatever type of script you want. Why do I need a tarball and not just an egg? Well, Debian (and I presume other) packaging systems always build from tarballs. There are also automated tools to check for the presence of new upstream tarballs. So if I am packaging zc.table for example and a committer makes a new egg-only release I have to take a number of extra steps: * Actually notice that there is a new release. * Download the tag, make a tarball, and upload it. Where to from here? I guess I could replace them with a make-a-release.py script which just invokes the setup.py script for the tarball and a list of python versions. Or we could enforce this within the setup.py (Too invasive in my opinion). -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zc.resourcelibrary/trunk/ A basic makefile, the ZPL and copyright headers.
On Thu, Jun 15, 2006 at 01:32:47PM -0400, Benji York wrote: > Brian Sutherland wrote: > > The reason I put them there in the first place is to nudge committers to > > create both the tarball and egg (for perhaps more than one python > > version) when creating a new release. > > I would prefer that be addressed outside of the source repository. > Perhaps Stephan's Zope Community site would be a good place to > accomplish this. I didn't know something like that existed. I'll have a look at it when I next I have time. > > The makefiles are not required and > > are trivially replacable by whatever type of script you want. > > I wouldn't want a bunch of identical (or near-identical) scripts, make > or otherwise, lying around. > > > Firstly, being the one that added these, i'll take them out/replace them > > according to the consensus. > > There seems to be a consensus (although not an overpowering one) that > they be removed. Enough for me. I removed all of them. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.interface using PyPy's extension compiler
At EuroPython I investigated re-implementing a class from zope.interface in PyPy's Restricted Python. I compiled it to C and then compared it to the Pure Python implementation and handcrafted C optimization. Not having touched PyPy before, I found it extreemly interesting. The report and code I wrote is available here for anyone else interested: http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ClientForm to a package
On Tue, Sep 26, 2006 at 11:08:54AM +0200, Philipp von Weitershausen wrote: > Stephan Richter wrote: > > On Tuesday 26 September 2006 04:14, Baiju M wrote: > >> Can we change `ClientForm` from a file based module > >> to a package. So that others can set it as svn:external (Zope 2 ?) > >> Let me do it in trunk? > > > > No, we are not maintaining ClientForm, so we do not have this freedom. > > I don't understand this. Turning it into a package would just mean > moving ClientForm.py to ClientForm/__init__.py, right? Yeah, and will break the zope3 zpkg setup and Debian packages. To name just two. Just please don't back-port this. > In either case, I would much prefer if we could just depend on it via eggs. +100 (But again, only on trunk.) -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ClientForm to a package
On Tue, Sep 26, 2006 at 12:02:29PM +0200, Philipp von Weitershausen wrote: > Brian Sutherland wrote: > > and Debian packages. > > I assumed they would not include ClientForm.py but simply depend on it > via dpkg? Yep, thats the way it's done, but Zope 3 tarballs come with ClientForm included. To remove something from the tarball, you have to know where it is. It's also easily fixed, but probably only after a re-build, distribution and user bug reports. Not nice for a bugfix release. > > Just please don't back-port this. > > Of course not. Great, that was my only point;) > >> In either case, I would much prefer if we could just depend on it via eggs. > > > > +100 (But again, only on trunk.) > > Yup. I really think buildout-ifying the Zope 3 checkout is the way to > go, especially because it would also mean we could get rid of our vendor > imports of 3rd party stuff and simply depend on them via setuptools. Not > entirely sure what an installation package of Zope 3 will then look > like, More than likely each egg would correspond to a package built from the source tarball. If you are interested, you can look at my efforts with the zc.* and hurry.* eggs/packages for the next schooltool release. The apt-source line is: deb-src ftp://ftp.schooltool.org/pub/schooltool/archives/debian unstable main You can install a python-zc.i18n package directly from there. > but I assume that it will be similar to a checkout (except for > development eggs): You'd download a bootstrap script that installs > everything into a specified location (where "everything") are eggs that > are either part of the distribution or will be loaded from the zope.org. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3+squid+Unauthorized = weirdness
On Wed, Dec 20, 2006 at 02:36:59PM +0100, Adam Groszer wrote: > Hello, > > Just happened the following: > >zope3 > server > | > | > squid proxy > / \ >/ \ > / \ > userA userB > > Both my users are sitting behind a squid proxy/firewall. > That is a usual out-of-the-box SuSe linux firewall/proxy config. > Each request goes through the squid proxy. > userA does NOT have permission to http://zope3/ap_test/folder1. > userB has permission to everything, including http://zope3/ap_test/folder1, > he might even be a zope.manager. > > 1. userA accesses http://zope3/ap_test/folder1 > 2. userA gets the usual "Unauthorized, You are not authorized" message > 3. userB accesses http://zope3/ap_test/folder1 > 4. BANG!, userB gets also the "Unauthorized, You are not authorized" message > > Investigating further, the request at 3. does not get to the zope3 > server. It got served by squid. > > Adding the "no-store, no-cache, must-revalidate" etc. headers to the > Unauthorized page solves the problem. > > Any opinions about that? Is it my mistake, a squid bug, a Z3 bug? Er, more like a squid feature, see negative_ttl. Not sure what the best way is to get around this though, "no-cache" is probably reasonable. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Fri, Jan 05, 2007 at 10:29:03AM -0500, Jim Fulton wrote: > Reinoud van Leeuwen wrote: > > On Wed, Jan 03, 2007 at 05:12:18PM -0500, Jim Fulton wrote: > >> Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances > > [...] > >> I should note that there have been a number of sucessful Zope 3 > >> applications that were not the OFS. In fact, some of the earliest > >> production Zope 3 applications were not based on the OFS. > > > > One of the first Zope 3 applications I looked at was SchoolBell. I was > > charmed by the elegant structure after install: a bunch of libraries > > somewhere, and a single instance directory containing a configuration file > > (for SchoolBell only, not Zope), and start and stop scripts. The Data.fs > > file was built during the first run. > > Where did log files end up? How about the zademon socket file? There is no zdaemon socket file, the server is daemonized using the -d option. Instances can be created and the logs are stored as in Zope3. Providing daemon start/stop capability is left up to operating system tools. As a packaged distribution (dpkg) the daemon control is a standard lsb compliant shell script that calls start-stop-daemon. Note that schooltool only really supports production use as a packaged application at this point. > > As a system administrator, this is how I like to see applications. > > That's interesting. As a developer, I like things to be > self contained. Most Unix system administrators I know want me > to follow standard Unix file-system layour conventions (e.g. > http://www.pathname.com/fhs/). Wearing my sysadmin cap, I'd like to say +100 to following the FHS. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up dependencies for Zope 3.4 eggs
On Thu, Apr 05, 2007 at 11:34:50AM -0400, Stephan Richter wrote:
> On Thursday 05 April 2007 11:08, Bernd Dorn wrote:
> > i use this tiny script
> >
> > http://svn.zope.org/z3c.configurator/trunk/importchecker.py?
> > rev=73771&view=log
>
> Right, I know about the importchecker. But it does nto generate the
> dependency
> tree for me and is agnostic to optional dependencies, which are supported by
> setuptools. I really want to hook into the dependencies of the setup script.
This is the way I'm using to get at the config of setup.py in some of my
tools:
from distutils.core import run_setup
dist = run_setup('setup.py', stop_after='config')
Then, it get's a little complex to actually get the data you want. I've
been doing something like:
from pkg_resources import parse_requirements
requires = parse_requirements(dist.install_requires)
for req in requires:
if req.specs:
for spec in req.specs:
op, version = spec
print '%s (%s %s)' % (req.project_name, op, version)
>
> Regards,
> Stephan
> --
> Stephan Richter
> CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
> Web2k - Web Software Design, Development and Training
> ___
> Zope3-dev mailing list
> Zope3-dev@zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de
>
>
--
Brian Sutherland
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3 without ZODB (redux)
Reading this thread made me want to try out some stuff: http://mail.zope.org/pipermail/zope3-dev/2007-January/021612.html So I've made a jinty-zodbless branch of the trunk and want to ask for comment on some of the design decisions I've made there before I spend a lot of time writing tests/examples and generally fixing things. The actual change is: http://mail.zope.org/pipermail/zope3-checkins/2007-April/029097.html -- Brian Sutherland ___ 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 without ZODB (redux)
On Thu, Apr 05, 2007 at 01:49:07PM -0400, Stephan Richter wrote: > On Thursday 05 April 2007 12:50, Brian Sutherland wrote: > > Reading this thread made me want to try out some stuff: > > > > � � http://mail.zope.org/pipermail/zope3-dev/2007-January/021612.html > > > > So I've made a jinty-zodbless branch of the trunk and want to ask for > > comment on some of the design decisions I've made there before I spend a > > lot of time writing tests/examples and generally fixing things. > > > > The actual change is: > > > > � � http://mail.zope.org/pipermail/zope3-checkins/2007-April/029097.html > > I think this looks good. The only concern I have is with the > term "IResourceFactory", since it already has a meaning in Zope 3. On the > other hand, this is a very different component, so you should be fine. Ok, I'm mostly done with what I wanted to do on that branch. I want to give people a chance to review it (feel free to commit directly to the branch) so I'll leave it on the branch for about 2 weeks before trying to merge it to the trunk. > I think that an added bonus would be to provide a demo on how to hook up an > ORM to this new setup. I added a zodb.app.zodbless module to the branch which is an example of a non-zodb zope3 app setup. I probably won't merge zodb.app.zodbless to the trunk because it has no tests. As for hooking up an ORM. I'm not sure what is the "right way" to do it. I'm even not sure about ORM in general anymore. But if I were to try, I would start with something very similar to zope.app.zodbless and then register custom traversers/views. The RDB connections would be defined in site.zcml as global utilities. The ORM gateways would also be global utilities, but defined in the zcml of the application. > > Regards, > Stephan > -- > Stephan Richter > CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) > Web2k - Web Software Design, Development and Training > -- Brian Sutherland ___ 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 without ZODB (redux)
On Tue, Apr 10, 2007 at 04:29:57PM +0530, Baiju M wrote: > Brian Sutherland wrote: > > >Ok, I'm mostly done with what I wanted to do on that branch. I want to > >give people a chance to review it (feel free to commit directly to the > >branch) so I'll leave it on the branch for about 2 weeks before trying > >to merge it to the trunk. > > > I am getting an error when running from an instance after > removing zodb section in etc/zope.conf > > File "./bin/runzope", line 48, in ? > run() > File "./bin/runzope", line 44, in run > main(["-C", CONFIG_FILE] + sys.argv[1:]) > File "/mbaiju/wa/jinty-zodbless/src/zope/app/twisted/main.py", line > 76, in main > service = setup(load_options(args)) > File "/mbaiju/wa/jinty-zodbless/src/zope/app/twisted/main.py", line > 145, in setup > app_factory = appsetup.setup_app_factory(options.databases) > File "/mbaiju/wa/jinty-zodbless/src/zope/app/appsetup/appsetup.py", > line 221, in setup_app_factory > db = multi_database(database_factories)[0][0] > IndexError: list index out of range Thanks for having a look! You need to register an zope.app.appsetup.interfaces.IApplicationFactory utility if you want to be able to remove the section from the config file. (look in zope.app.zodbless on the branch) I'll make the error message more explicit. > > > Regards, > Baiju M > > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > > -- Brian Sutherland ___ 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.rdb error and zope.publisher error
On Thu, Apr 26, 2007 at 02:53:54PM +0200, Maciej Wisniowski wrote: > Possibly it is enough to change above code to something like: > > try: > cursor.execute(query) > except Retry: > raise > except ConflictError: > raise > except Exception, error: > # Just catch the exception, so that we can convert it to a database > # exception. > raise DatabaseException(str(error)) > > Any thoughts? I would personally be in favour of just ripping out DatabaseException entirely and letting the original errors propagate. It's caused me a lot of pain in the past by hiding real problems. I have never seen any use for it. -- Brian Sutherland ___ 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.rdb error and zope.publisher error
On Thu, Apr 26, 2007 at 11:09:17PM +0200, Maciej Wisniowski wrote: > > I would personally be in favour of just ripping out DatabaseException > > entirely and letting the original errors propagate. It's caused me a lot > > of pain in the past by hiding real problems. > > > > I have never seen any use for it. > I think zope/rdb tries to be as general as possible, so using > DatabaseException for all RDBMS errors may be sometimes desirable > especially if someone builds application that > shouldn't be bound to one, specific database adapter. But I think it > is rather rare(?) situation, > and there are still generic errors > like cx_oracle.Error or psycopg.Error. They're DBMS aware but > it shouldnt be hard to write a common handler or something like > that if someone has to just handle all DBMS errors at once. There are the ORM mappers SQLObject and SQLAlchemy which try to work across different databases. But both of these seem to have specific backends for each database they support, in which case a generic exception like zope.rdb.interfaces.DatabaseException is not useful at all. In fact, it was when I was trying to integrate SQLObject and zope3 that I developed my hatred for zope.rdb.interfaces.DatabaseException. An interesting way that SQLObject tries to get around this issue is to have a module attribute on the database connection. So then the original DatabaseException from the dbapi module is always at conn.module.DatabaseException. But I'm not sure zope.rdb should try that. > Current implementation may cause some problems if someone needs real > errors standarized by python dbapi. > For me it would be cleaner to just have standard dbapi errors in Zope. What does this mean? Are you suggesting implementing the full range of dbapi errors in zope.rdb? Or letting the real errors propagate? One problem with ripping out zope.rdb.interfaces.DatabaseException is backwards compatibility and deprecation. I can't think of any sane way to do that. -- Brian Sutherland ___ 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.rdb error and zope.publisher error
On Fri, Apr 27, 2007 at 02:02:35PM +0200, Maciej Wisniowski wrote: > > One problem with ripping out zope.rdb.interfaces.DatabaseException is > > backwards compatibility and deprecation. I can't think of any sane way > > to do that. > Right, so possibly first step should be to at last let Retry > and ConflictError errors propagate. I have no objections to your patch, I just thought I would suggest another way. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: what dependency to use for "zope 3"
On Fri, May 11, 2007 at 01:08:26PM -0400, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bernd Dorn wrote: > > On 11.05.2007, at 17:29, Chris Withers wrote: > > > >> Fred Drake wrote: > >>> On 5/11/07, Chris Withers <[EMAIL PROTECTED]> wrote: > >>>> I dunno, do we actually need an "offical big zope 3 release" > >>>> anymore? > >>> No. What's more, we don't even want to use one anymore. > >> cool :-) > >> > >> My only slight concern here is when people make changes in one > >> satellite project, they break another one and don't realise. But I > >> guess the buildbot should catch that, right? > > > > i talked with jim about this and we agreed in that specifying > > versions in eggs is not a good idea. The best way imho is to use > > buildout's 'version' section in your application's buildout to nail > > down all eggs to a specific version. > > - -1; a "meta" egg would work fine as a place to specify hard-wired > dependencies. Not every Zope3 user is going to be using buildout. > Note that such a "mega-egg" would likely specify the "transitive > closure" of its dependency graph, as well. It's just going to get very difficult very quickly to manage such a meta egg with over 100 or so dependencies. Though I guess there'll be automated tools to manage this. I think another alternative is to separate the releases into different "repositories", kinda like "All zope 3.0.0 eggs are at http://download.zope.org/distribution/3.0.0/";. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: what dependency to use for "zope 3"
On Fri, May 11, 2007 at 11:59:37PM +0100, Martin Aspeli wrote: > Brian Sutherland wrote: > > > It's just going to get very difficult very quickly to manage such a meta > > egg with over 100 or so dependencies. Though I guess there'll be > > automated tools to manage this. > > Better we do the difficult part than each and every user does it. I'm not saying "don't do it", but more "don't try do it by hand" or you'll burn out your release manager. A meta egg that only specifies a few dependencies is managable by hand, but a meta egg that exactly specifies over 100 packages and exact versions is not. > In the > ideal world, there are no version conflicts. In the real world, there will > be subtle version conflicts that mean that you can't just always get the > latest release of each egg. Yep. > Anyone who's used something like Gentoo Linux, > with frequent and unsynchronized releases of different products know what > happens when two packages require different version of the same library, or > some automatically updated package suddenly remove the little bit of the API > you were depending on. Yep, that's why you want some way to get a set of packages that work together for lots of people and an easy way to add bugfix releases to this set. But I do think that a hand-managed super meta-package is a very difficult thing to do. > Put differently, you may know that you need zope.annotation and > zope.app.content, but I suspect that most people won't quite know where to > start, and won't quite know what's available to them. If they start with > some particular dependency and start exploring the dependency graph, they'll > probably miss something that's either standalone or on a completely separate > dependency subtree to the one they're on. > > > I think another alternative is to separate the releases into different > > "repositories", kinda like "All zope 3.0.0 eggs are at > > http://download.zope.org/distribution/3.0.0/";. > > Having eggs doesn't absolve us from doing release management. :) Add a meta egg with a few non-versioned dependencies to the above collection of eggs and it becomes a release (or multiple releases) :) Anyone, as long as they only download eggs from that URL, it guaranteed a set of eggs that works well together. Bugfixes are simple, simply drop an egg in that directory. One very bad thing about such a URL is that it makes it very tempting for developers to upload forked versions of things like twisted, pytz or mechanize there. However, buildout's approach of "saving" a known good dependency tree is also reasonable: http://svn.zope.org/zc.buildout/trunk/specifications/repeatable.txt?view=auto Though I'm not sure how well it will deal with bugfix releases or allowing others to extend a release you make (i.e. plone on top of zope3). Perhaps even buildout can become the method to create a directory of eggs/tarballs that will be a "release". /me realizes that his hands are waving vigorously! > We still > need to take some of the pain of testing and making sure there are adequate > tests and making sure things work well together. It's part of the QA process > (which Zope 3 has done immensely well to date, in my opinion). If that > overall responsibility eventually falls on no-one, then I fear we'll lose > the great integration power we have in Zope 3 at the moment. I'm sure both the "repository" and "saved" release types can be tested together automatically using buildout. > Most people just want a "known good" that they can depend on, where they > know that changes are going to be limited to important bug fixes. They don't > care if they get ten extra packages, what's a few megabytes of disk space. Yep, for this you can have some meta packages with a few un-versioned dependencies in the included in the directory of "safe" packages. > It's all well and good (great, even) that people can specify their own > dependency subtrees (I need the annotation and component parts of Zope, I > don't want the rest), not at least because it gives entirely different > platforms a better chance of re-using our code, but someone still needs to > look after the whole. There are too many packages to have independent > maintainers who each (a) are available to do timely releases (b) don't > forget to make release after a while and (c) are able to test that the code > that is supposed to work with other things, continues to work with those > things. > > Martin > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > > -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On Mon, May 21, 2007 at 04:44:41PM +0200, Reinoud van Leeuwen wrote: > But as system maintainer I like to keep things simple. I do not want > similar trees of python installations all over the place if it can > be avoided. You're not alone:) I too much prefer to use system packages as much as possible to install software on production servers. There are quite a few reasons why things like buildout just don't do it for me. Mostly it's because my requirements are different from the people who want to use buildout. But then, I like eggs a lot as well, because the changes they are causing in the way people develop in python is making life easier for system packagers :) -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On Wed, May 23, 2007 at 09:37:33AM +0200, Philipp von Weitershausen wrote: > Marius Gedminas wrote: > > On Mon, May 21, 2007 at 10:44:47AM -0400, Jim Fulton wrote: > >> On May 21, 2007, at 1:39 AM, Martijn Pieters wrote: > >>> Come again? Using the system python when developing has always been > >>> fine; > >> No. It has never been fine for any aspect of development. If you develop > >> with your system Python and deploy with a custom environment, then you've > >> added a variable that is different between the two environments. Also, > >> system Python's are often hobbled in ways that hurt development. > >> > >> I sometimes get really weird error reports that are traced to system > >> Pythons. People who report problems to me that result from using a > >> system Python make me angry and make me want to not answer their > >> questions or otherwise help them any more. > > I'd love to hear some anecdotes about this. The ones I know about: > > * distros releasing newer point versions of Python with security fixes > > (cgi.FieldStorage) that break Zope 3 > > I consider that a major show-stopper. An innocent "apt-get upgrade" pulls in > Python 2.4.4c0 and all of a sudden all your Zope apps break! Well not mine, > I use self-compiled Pythons for my production servers... Was that a security update to a "released" version? Otherwise it's not so innocent for a production system;) btw, in future, it is planned to integrate the zope3 tests with autopkgtest, http://packages.debian.org/unstable/devel/autopkgtest. Which should mean that this kind of breakage will happen less as autopkgtest basically is running the tests of installed packages on installed packages. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Releasing zope.wfmc and zope.app.wfmc?
Hi, In schooltool, we depend on zope.wfmc and zope.app.wfmc, and we want to make a release sometime. Unfortunately it looks like those have never been released with zope 3 or individually. Anyone object to me making a release of these two from the current trunk and uploading it to http://download.zope.org/distribution/ ? -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Releasing optionstorage
SchoolTool finds itself depending on optionstorage, which is a very zope specific egg. It has never been released, despite being in subversion for a long time. Firstly, I'd like to make the first release of an optionstorage egg so that SchoolTool can depend on it. Objections? However, before I do that, I would like to place the egg and module into a namespace package leaving svn externals as the only backwards compatibility. I don't particularly care which namespace package so suggestions would be appreciated. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Releasing optionstorage
On Wed, Jun 20, 2007 at 12:17:56PM +0200, Philipp von Weitershausen wrote: > Brian Sutherland wrote: >> SchoolTool finds itself depending on optionstorage, which is a very zope >> specific egg. It has never been released, despite being in subversion >> for a long time. >> Firstly, I'd like to make the first release of an optionstorage >> egg so that SchoolTool can depend on it. Objections? > > Nope :). Yay:) >> However, before I do that, I would like to place the egg and module into >> a namespace package leaving svn externals as the only backwards >> compatibility. I don't particularly care which namespace package so >> suggestions would be appreciated. > > Not sure if we care about backward compatibility here. What's wrong with > just leaving the module name to be "optionstorage"? optionstorage is heavily zope-specific, but it's name communicates nothing of the sort. I don't think it's polite for us to pollute the top level namespace with many zope-specific packages. So, I think its place is in one of the zope namespaces. I just wanted to correct that before the first release (and before we have to maintain backwards compatibility). > Other than that, the 'z3c' namespace seems to have become the standard > community namespace nowadays. Great, that sounds like a good place! -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zope.html/trunk/ZopePublicLicense.txt Add the ZPL text.
On Wed, Jul 11, 2007 at 08:45:41AM -0400, Benji York wrote: > Fred Drake wrote: >> It seems that if the ZPL is required to be in distributions, it needs >> to be added to the result of "setup.py sdist" and the various bdist_* >> commands (including bdist_egg). > > +lots As long as it's in the tarball, I'm happy (though I suppose the eggs need it too). Any suggestions as to how to get the actual text when building the tarball? I can see 3 options: * svn export * HTTP GET * Put it inside the setup.py. None of them is very appetizing. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zope.html/trunk/ZopePublicLicense.txt Add the ZPL text.
On Wed, Jul 11, 2007 at 01:48:44PM -0400, Fred Drake wrote: > On 7/11/07, Brian Sutherland <[EMAIL PROTECTED]> wrote: >> Any suggestions as to how to get the actual text when building the >> tarball? > ... >> None of them is very appetizing. > > No, they're not. Anyone wonder why developers treat packagers and > lawyers like idiots? Anything to keep us from getting work done Yeah, I know what you mean, I think physicists are idiots as well. They keep on telling me I can't have those X-ray glasses I've wanted for such a long time. Though I probably get more work done without those;) -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] AW: Proposal, free views
On Mon, Sep 24, 2007 at 01:13:00AM +0200, Roger Ineichen wrote: > I think we will split packages in its base parts. > For exapmle this means we will create a package zope.session > that contains the python api and degrade zope.app.session > to contain the zmi views. Personally, I think this is the way to go. i.e. to separate the UI from the python API in separate eggs. That way the python API egg can have relatively few dependencies, and thus be more useful to more people. The UI egg is then useful to whoever wants to bring in all the dependencies and conform to the UI. It's very strange the way Zope3 mixes high-level code (css, html, pagetemplates) with low-level python APIs. Basically forcing you to have (and manage) lots of dependencies even if you only want the python API. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
On Wed, Sep 26, 2007 at 08:22:48PM -0400, Tres Seaver wrote: > Anybody running against the Cheeseshop today is *more* on the bleeding > edge than a sysadmin whose production boxes are running 'sid': Debian > has cultural constraits, even for that distro, which are vastly more > restricted than the Wild West which is PyPI. > > The only solution I can see is to create filtered subsets / mirrors of PyPI. There is one I thought of, but it's a bit backwards. Essentially, Debian has a repository of mostly unmodified original egg tarballs. And, they've already done the hard work of maintaining sane dependencies. So, why not simply re-name the .orig.tar.gz in a Debian release repository to their original names and you have a working set corresponding to that release. If you add your selected personal working set, then you have a basis for working without bleeding. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
On Thu, Sep 27, 2007 at 11:11:06PM +0200, Martijn Faassen wrote: > Hey, > > On 9/27/07, Brian Sutherland <[EMAIL PROTECTED]> wrote: > [snip] > > There is one I thought of, but it's a bit backwards. > > > > Essentially, Debian has a repository of mostly unmodified original egg > > tarballs. And, they've already done the hard work of maintaining sane > > dependencies. > > > > So, why not simply re-name the .orig.tar.gz in a Debian release > > repository to their original names and you have a working set > > corresponding to that release. > > > > If you add your selected personal working set, then you have a basis for > > working without bleeding. > > Does it contain the Zope 3.4 eggs? No. But then my point wasn't that you would use it for Zope3 eggs, but for everything else. There's a lot of eggs, even in etch. And in lenny there will be even more. There are few pre-release/alpha/beta versions of eggs. In fact, a lot of maintainers prefer to release older/stabler versions than the latest release. And the only changes that happen to releases are security updates. Think of it as a stable base upon which to build. > Will it have Zope 3.5 eggs when we > need them? As above, not the point. > I think if we're going to manage our own gated community, > it'll be something we need to do ourselves. I just see the need for 1 > per release of piece of software (grok 0.10, grok 0.11, etc), and only > a vague idea how frameworks would work (I want to use the Foo gated > community which also uses the Grok gated community) so I must be > missing something. Now, how would you use the Grok gated community with the sqlalchemy gated community if they had common dependencies, and those dependencies were at different versions in the two communities? Of course, you could make one _very_ large gated community and "freeze" it as a release every now and then. Er, basically the same as what distros are doing, hopefully making their life much easier;) > > Regards, > > Martijn > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] psycopgda egg
On Wed, Oct 10, 2007 at 11:27:14AM -0300, Sidnei da Silva wrote: > Has anyone eggified psycopgda? I can't find mention of an egg for it > anywere. I would be pretty surprised that no-one did this so far. psycopg2da comes with the psycopg2 tarball, but I'm not sure if it will be included in a psycopg2 egg. > > -- > Sidnei da Silva > Enfold Systemshttp://enfoldsystems.com > Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Mon, Oct 08, 2007 at 06:49:02PM -0400, Stephan Richter wrote: > On Monday 08 October 2007 15:09, Tres Seaver wrote: > > Presuming agreement on the "known good set" (KGS) term, I would think > > that we have two candidates for what makes up "platform releases" > > > > Frozen Releases > > > > I started commenting this section until I saw the one below. I personally do > not see much benefit from the frozen release. That said, it would be trivial > to create one from the updateable version below. I have already scripts for > this, which are checked in as part of Jim's PyPI mirror tool. A frozen release is very useful for some people (as long as it also gets security updates). -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Bits from debconf
At debconf 5 a group of debian developers met about zope packaging in debian (Minutes at [1]). I would like to let you guys know what went on and hopefully get some advice. We plan to improve the maintenance of zope packages in debian through group maintenance and making it easier to maintain products included in instances. Specifically, some of the plans are: * Maintain all the zope packages in Debian as a group. * Alert when an attempt is made to de-install a Product package which is installed in some instances. * Provide per instance manual upgrade procedures according to the installed products. * Resolve product dependencies in instances, e.g. provide a tool which will automatically install schoolbell if schooltool is install in an instance. * Product dependencies in instances should also be re-computed on upgrading a Product package. * Re-start instances on re-boot, wherever they are on the filesystem. * Have a common repository for packaging code. Quite a bit of work has been completed thus far (dzhandle, zope-pkg-developers), with more to come. Where is makes sense we will try to implement the features in a general way useful to others outside the Debian world. In particular, I think that the product dependency resolving tool should be implemented within zope (using ZCML perhaps) rather than debian and would appreciate any advice. Thanks for making it to the end of the mail;) [1] http://debian.madduck.net/pkg-zope/wiki/Administrativa/Minutes/DebConf5Kickoff -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Thu, Nov 03, 2005 at 12:08:09PM +0100, Andres Freund wrote: > 4. Every database adapter has an own interface which inherits from the > zope one. This would enable the use of normal zope adaption which i > would prefer, but again every adapter which should be used together > with sqlos has to be changed. This is also my slightly preferred option. It could work for mysql as follows (/me waves hands rapidly): 1. zope.app.rdb define IMySQLZopeConnection which extends IZopeConnection. IMySQLZopeConnection is just a marker interface. 2. in sqlos register an adapter from IMySQLZopeConnection to sqlos to the IZopeSQLConnection. 3. in mysqldbda provide an implementation of IMySQLZopeConnection, i.e. returns objects implementing IMySQLZopeConnection in place of IZopeConnection -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Thu, Nov 03, 2005 at 12:48:40PM +0100, Brian Sutherland wrote: > On Thu, Nov 03, 2005 at 12:08:09PM +0100, Andres Freund wrote: > > 4. Every database adapter has an own interface which inherits from the > > zope one. This would enable the use of normal zope adaption which i > > would prefer, but again every adapter which should be used together > > with sqlos has to be changed. > > This is also my slightly preferred option. It could work for mysql as > follows (/me waves hands rapidly): > > 1. zope.app.rdb define IMySQLZopeConnection which extends > IZopeConnection. IMySQLZopeConnection is just a marker interface. > 2. in sqlos register an adapter from IMySQLZopeConnection to sqlos to the > IZopeSQLConnection. > 3. in mysqldbda provide an implementation of IMySQLZopeConnection, i.e. > returns objects implementing IMySQLZopeConnection in place of > IZopeConnection So, this is the code I will commit to the mysqldbda (similar code may eventually make it's way into the other database adapters): Index: ../mysqldbda/adapter.py === --- ../mysqldbda/adapter.py (revision 39859) +++ ../mysqldbda/adapter.py (working copy) @@ -16,11 +16,17 @@ $Id: Adapter.py,v 1.1 2004/10/10 mriya3 """ +from zope.interface import directlyProvides +from zope.app.rdb.interfaces import IZopeConnection from zope.app.rdb import ZopeDatabaseAdapter, parseDSN import MySQLdb +class IMySQLZopeConnection(IZopeConnection): +"""A marker interface stating that this connection uses the MySQL SQL.""" + + class MySQLStringConverter: def __init__(self, encoding): @@ -66,3 +72,8 @@ def identity(self, x): return x + +def __call__(self): +connection = ZopeDatabaseAdapter.__call__(self) +directlyProvides(connection, IMySQLZopeConnection) +return connection And how it is used in sqlos: Index: sqlos/src/sqlos/configure.zcml === --- sqlos/src/sqlos/configure.zcml (revision 19326) +++ sqlos/src/sqlos/configure.zcml (working copy) @@ -1,5 +1,6 @@ http://namespaces.zope.org/zope"; xmlns:browser="http://namespaces.zope.org/browser"; + xmlns:zcml="http://namespaces.zope.org/zcml"; i18n_domain="sqlos"> @@ -145,6 +146,15 @@ /> --> + + + + http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Mon, Nov 07, 2005 at 09:14:34AM -0500, Stephan Richter wrote: > On Monday 07 November 2005 08:52, Brian Sutherland wrote: > > On Thu, Nov 03, 2005 at 12:48:40PM +0100, Brian Sutherland wrote: > > > On Thu, Nov 03, 2005 at 12:08:09PM +0100, Andres Freund wrote: > > > > 4. Every database adapter has an own interface which inherits from the > > > > zope one. This would enable the use of normal zope adaption which i > > > > would prefer, but again every adapter which should be used together > > > > with sqlos has to be changed. > > > > > > This is also my slightly preferred option. It could work for mysql as > > > follows (/me waves hands rapidly): > > > > > > 1. �zope.app.rdb define IMySQLZopeConnection which extends > > > � � IZopeConnection. IMySQLZopeConnection is just a marker interface. > > > 2. �in sqlos register an adapter from IMySQLZopeConnection to sqlos to > > > the IZopeSQLConnection. > > > 3. �in mysqldbda provide an implementation of IMySQLZopeConnection, i.e. > > > � � returns objects implementing IMySQLZopeConnection in place of > > > � � IZopeConnection > > > > So, this is the code I will commit to the mysqldbda (similar code may > > eventually make it's way into the other database adapters): > > Please don't check this in yet, I want to review the problem before you do, > because I think specific interfaces are just nuts unless we have a very good > reason. Sure;) The guts of the issue are how to know what type of SQL the connection accepts so that sqlos can choose the right adapter for it. An interface seemed best. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Sat, Nov 12, 2005 at 06:53:23AM -0500, Stephan Richter wrote: > On Monday 07 November 2005 10:18, Brian Sutherland wrote: > > > Please don't check this in yet, I want to review the problem before you > > > do, because I think specific interfaces are just nuts unless we have a > > > very good reason. > > > > Sure;) > > > > The guts of the issue are how to know what type of SQL the connection > > accepts so that sqlos can choose the right adapter for it. An interface > > seemed best. > > After thinking about it on and off for the last week, I agree now. The > simplest, easiest and most effective solution are specific interfaces. *sigh* Yeah, I just found zope.schema.interfaces and now understand your sigh. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 tarball build/test run log
unning samplelayers.Layer1 tests:
DEBUG: Set up samplelayers.Layer1 in N.NNN seconds.
DEBUG: Ran 9 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer11 tests:
DEBUG: Set up samplelayers.Layer11 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer111 tests:
DEBUG: Set up samplelayers.Layerx in N.NNN seconds.
DEBUG: Set up samplelayers.Layer111 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer112 tests:
DEBUG: Tear down samplelayers.Layer111 in N.NNN seconds.
DEBUG: Set up samplelayers.Layer112 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer12 tests:
DEBUG: Tear down samplelayers.Layer112 in N.NNN seconds.
DEBUG: Tear down samplelayers.Layerx in N.NNN seconds.
DEBUG: Tear down samplelayers.Layer11 in N.NNN seconds.
DEBUG: Set up samplelayers.Layer12 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer121 tests:
DEBUG: Set up samplelayers.Layer121 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Running samplelayers.Layer122 tests:
DEBUG: Tear down samplelayers.Layer121 in N.NNN seconds.
DEBUG: Set up samplelayers.Layer122 in N.NNN seconds.
DEBUG: Ran 34 tests with 0 failures and 0 errors in N.NNN seconds.
DEBUG: Tearing down left over layers:
DEBUG: Tear down samplelayers.Layer122 in N.NNN seconds.
DEBUG: Tear down samplelayers.Layer12 in N.NNN seconds.
DEBUG: Tear down samplelayers.Layer1 in N.NNN seconds.
DEBUG: Total: 405 tests, 0 failures, 0 errors
DEBUG: False
DEBUG: --
DEBUG: File
"/home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt",
line 86, in testrunner-coverage.txt
DEBUG: Failed example:
DEBUG: os.path.exists('coverage_dir')
DEBUG: Expected:
DEBUG: True
DEBUG: Got:
DEBUG: False
DEBUG: --
DEBUG: File
"/home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt",
line 88, in testrunner-coverage.txt
DEBUG: Failed example:
DEBUG: os.listdir('coverage_dir')
DEBUG: Exception raised:
DEBUG: Traceback (most recent call last):
DEBUG: File
"/home/jinty/releases/Zope3/z/../tst/lib/python/zope/testing/doctest.py", line
1256, in __run
DEBUG: compileflags, 1) in test.globs
DEBUG: File "", line 1, in ?
DEBUG: OSError: [Errno 2] No such file or directory: 'coverage_dir'
DEBUG: --
DEBUG: File
"/home/jinty/releases/Zope3/tst/lib/python/zope/testing/testrunner-coverage.txt",
line 94, in testrunner-coverage.txt
DEBUG: Failed example:
DEBUG: shutil.rmtree('coverage_dir')
DEBUG: Exception raised:
DEBUG: Traceback (most recent call last):
DEBUG: File
"/home/jinty/releases/Zope3/z/../tst/lib/python/zope/testing/doctest.py", line
1256, in __run
DEBUG: compileflags, 1) in test.globs
DEBUG: File "", line 1, in ?
DEBUG: File "/usr/lib/python2.4/shutil.py", line 151, in rmtree
DEBUG: onerror(os.listdir, path, sys.exc_info())
DEBUG: File "/usr/lib/python2.4/shutil.py", line 149, in rmtree
DEBUG: names = os.listdir(path)
DEBUG: OSError: [Errno 2] No such file or directory: 'coverage_dir'
DEBUG:
DEBUG: Ran 7645 tests with 1 failures and 0 errors in 397.956 seconds.
DEBUG: Running zope.app.testing.functional.Functional tests:
DEBUG: Set up zope.app.testing.functional.Functional in 4.823 seconds.
DEBUG: Ran 459 tests with 0 failures and 0 errors in 119.794 seconds.
DEBUG: Tearing down left over layers:
DEBUG: Tear down zope.app.testing.functional.Functional ... not supported
DEBUG: Total: 8104 tests, 1 failures, 0 errors
>
> ___
> Zope3-dev mailing list
> Zope3-dev@zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de
>
>
--
Brian Sutherland
Metropolis - "it's the first movie with a robot. And she's a woman.
And she's EVIL!!"
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
Since we are close to the release, I felt compelled to ask before I did this. Could I revert 39890 [1] for the 3.2 release? It seems that phillip finished zpkg's module support some time ago [2]. (I ask as this is causing me headaches doing the Debian packaging for the latest zope3) [1] http://mail.zope.org/pipermail/zope3-checkins/2005-November/026485.html [2] http://mail.zope.org/pipermail/zpkg/2005-November/77.html -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 03, 2006 at 07:13:16AM -0500, Jim Fulton wrote: > Brian Sutherland wrote: > > Since we are close to the release, I felt compelled to ask before I did > > this. Could I revert 39890 [1] for the 3.2 release? > > No. Ok, good thing I asked first then;) I'll work around it or wait. > Why wait until we are close to the release? Because I only realized it was causing a headache for me yesterday. > > It seems that phillip finished zpkg's module support some time ago [2]. > > > > (I ask as this is causing me headaches doing the Debian packaging for > > the latest zope3) > > The first beta was nearly 2 months ago. We are trying to do timed releases > and we've already missed the deadline. I'm not willing to delay 3.2 final > for this. > > I am willing to consider a 3.2.1 release for this *after* the final. That would also be fine. > Why do you think you need to do this? It is related to the debian packaging of zope 3. It is common practice with these packages to remove modules that can be provided by other debian packages. So far this has been the case only with pytz and docutils. The relevant code in the debian rules file is (yes, I know it is nasty, but there doesn't seem to be a "right way"): zbase= Zope-3.2.0b2 unpack: unpack-stamp unpack-stamp: tar xfz $(zbase).tgz mv $(zbase) z # Remove docutils and pytz modules packaged in separate packages rm -rf z/Dependencies/docutils* rm -rf z/Dependencies/pytz* I also need to do the same with mechanize and it's dependencies. Since the latest version of mechanize depends on pullparser 0.0.7, I also need to remove pullparser. This is more difficult with the way pullparser is tied into zope today. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 03, 2006 at 10:51:04AM -0500, Jim Fulton wrote: > Brian Sutherland wrote: > > On Tue, Jan 03, 2006 at 07:13:16AM -0500, Jim Fulton wrote: > > Because I only realized it was causing a headache for me yesterday. > > I greatly appreciate your working on Debian packaging. I encourage > you to take time-based releases into account when doing this. You should > try to create Debian based on each of our beta releases, so you don't find out > late that there is a problem. Yeah, I know:( > >>I am willing to consider a 3.2.1 release for this *after* the final. > > > > > > That would also be fine. > > OK, if you want to proceed with this, then we'll do that. Ok, I committed my patches to the trunk. > >>Why do you think you need to do this? > > > > > > It is related to the debian packaging of zope 3. It is common practice > > with these packages to remove modules that can be provided by other > > debian packages. So far this has been the case only with pytz and docutils. > > I'm guessing that this is an issue because you install > Zope's into site-packages and you don't want a Zope installed > package to clobber a package that is separately packaged. Is that right? Yes, also so that if someone wants to use mechanize, they don't have to install zope3... > The normal way to install Zope is in it's own directory. In this case it becomes a lot more difficult for other programs to use parts of zope (zope.interface or ZConfig comes to mind). For example, my schooltool packages can just do "import zope", and it is there. No additions to sys.path necessary. > In this case, > a package supplied with Zope only affects Zope. In which case, I don't > see the need to rip it out. In fact, I would prefer that Zope use the > versions of packages that came with it, since these are the versions > it has been tested with. OTOH, if you create a distribution that omits > packages that are provided separately, you are taking on responsibility for > assuring that the installed Zope works properly. I can understand why you > would want to do this. Hopefully running the tests without the removed packages will be enough. I also try only to take these steps with code that is definitively from a different project (mechanize, pytz, docutils) and is useful in it's own right. Actually it is pretty easy to set up a debian chroot which upgrades itself and tests its Zope 3 installation every week or so. But I am missing both the time and hardware. > > The relevant code in the debian rules file is (yes, I know it is nasty, > > but there doesn't seem to be a "right way"): > > > > zbase= Zope-3.2.0b2 > > > > > > > > unpack: unpack-stamp > > unpack-stamp: > > tar xfz $(zbase).tgz > > mv $(zbase) z > > # Remove docutils and pytz modules packaged in separate packages > > rm -rf z/Dependencies/docutils* > > rm -rf z/Dependencies/pytz* > > > > I also need to do the same with mechanize and it's dependencies. Since > > the latest version of mechanize depends on pullparser 0.0.7, I also need > > to remove pullparser. This is more difficult with the way pullparser > > is tied into zope today. > > Pullparser is currently distributed within the zope.testbrowser package. > It can't interfere with anything else. I suppose you just want to eliminate > the duplication. No, it's worse than that. I am trying to use mechanize 0.0.11a which depends and tests for pullparser 0.0.7. Since zope includes an older pullparser and then mungs sys.modules, it causes the mechanize in site-packages to fail. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 tarball build/test run log
On Wed, Jan 04, 2006 at 07:08:59AM -0500, Jim Fulton wrote: > Brian, > > What are you trying to accomplish with this test? This is the result of building and testing the tarball/multiple tarballs. I started this because zope3 was breaking my schooltool nightly tarball build too often. Practically all of my commits over the last months have been fixing tarball setup breakage caught by this test. I wanted others to help as well;) > I think buildbot does a better > job. If there is a function you'd like to suggest for our emerging buildbot > setup, > I'd like to hear it. Yes, building and testing tarballs. Another interesting idea is testing old bodies of code against newer Zope 3 versions. For backwards compatibility. For example, schoolbell, released with Zope 3.1 fails its tests with Zope3.2. > A message like this, with no useful information might as well be spam. I agree, and have stopped forwarding these messages until I can be certain they will be more useful. Even before you sent this mail;) -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 tarball build/test run log
On Wed, Jan 04, 2006 at 11:29:47AM -0500, Jim Fulton wrote: > Brian Sutherland wrote: > > Yes, building and testing tarballs. > > What does this mean? What tar balls? Do you mean releases? basically the contents of releases/Zope-test.py. For schooltool, the testing script I use is the same as the script I use to make a schooltool release. In fact the products of these tests are called the schooltool nightly tarballs and are actually released. > > Another interesting idea is testing old bodies of code against newer > > Zope 3 versions. For backwards compatibility. For example, schoolbell, > > released with Zope 3.1 fails its tests with Zope3.2. > > I think this is a great idea. We do this internally. Of course, > it doesn't make sense to send schoolbell test failures to the Zope 3 list. > It does often make sense to raise breakage issues in the collector, > or on the list. Great, here is the first: from zope.server.http.publisherhttpserver import PublisherHTTPServer Traceback (most recent call last): File "test.py", line 1115, in ? exitcode = main(sys.argv) File "test.py", line 1077, in main test_cases = get_test_cases(test_files, cfg, tracer=tracer) File "test.py", line 333, in get_test_cases test_suite = func() File "/home/jinty/src/schooltoolrepo/schoolbell-1.2.x/src/schoolbell/app/tests/test_main.py", line 630, in test_suite optionflags=doctest.ELLIPSIS), File "/home/jinty/src/schooltoolrepo/schoolbell-1.2.x/Zope3/src/zope/testing/doctest.py", line 2334, in DocTestSuite module = _normalize_module(module) File "/home/jinty/src/schooltoolrepo/schoolbell-1.2.x/Zope3/src/zope/testing/doctest.py", line 235, in _normalize_module return __import__(module, globals(), locals(), ["*"]) File "/home/jinty/src/schooltoolrepo/schoolbell-1.2.x/src/schoolbell/app/main.py", line 49, in ? from zope.app.server.http import http ImportError: No module named http -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 10, 2006 at 11:27:18AM -0500, Jim Fulton wrote: > BTW, wrt versions, it seems to be a common practice to treat different > versions as separate packages. For example, on my Ubuntu system, > Berkeley DB 4.2 and 4.3 are treated as separate (sets of) packages. Yes it is common, but the maintenance burden is higher. Also, if you can avoid it, why do you want two sets of packages that do the same thing? I am not fully convinced that zope 3 on the python path is workable, time will tell. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 03, 2006 at 06:35:11PM +0100, Brian Sutherland wrote: > On Tue, Jan 03, 2006 at 10:51:04AM -0500, Jim Fulton wrote: > > >>I am willing to consider a 3.2.1 release for this *after* the final. > > > > > > > > > That would also be fine. > > > > OK, if you want to proceed with this, then we'll do that. > > Ok, I committed my patches to the trunk. And have back-ported them to the release branch in 41261. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: rdb: Disappearing Connection
Hi, Thanks for posting this, it saved me quite a few hours. On Fri, Dec 16, 2005 at 04:23:36PM -0500, Jim Washington wrote: > def isConnected(self): > try: > self._v_connection.ping() > except: > # not connected or ping did not restore MySQL connection > if self._v_connection is not None: > self._v_connection.close() > self._v_connection = None > return False > return True I have two comments that I noticed: * If the connection was closed directly, by something else, you can fail when you try to close the connection: File "/home/jinty/src/Z3/z3/src/mysqldbda/adapter.py", line 87, in isConnected self._v_connection.close() ProgrammingError: closing a closed connection Which means that _v_connection will not be set to None and it will carry on failing. * Also, if, in this transaction, some SQL has been sent through the connection, the connection will have registered itself with the transaction manager. This made both aborting and commiting the transaction fail for me. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/branches/3.2/ - Declare the zope top-level package as a namespace package if
On Thu, Jan 26, 2006 at 09:50:29AM -0200, Sidnei da Silva wrote: > On Wed, Jan 25, 2006 at 04:37:45PM -0200, Sidnei da Silva wrote: > | On Wed, Jan 25, 2006 at 01:30:41PM -0500, Stephan Richter wrote: > | | Please revert this revision. As you admit yourself in CHANGES.txt, this > is a > | | new feature. You cannot add new features to a dot release branch. > | > | Well, I would go as far as calling it a bugfix. Will revert it then we > | can discuss. > > Sorry, I've removed some context from this email, so I guess nobody > understood what it is about. > > I had added a call to pkg_resource.declare_namespace() to Zope 3's > zope/__init__.py, which enables one to have sub packages of 'zope' > distributed as eggs. > > Stephan complained that this is not a 'bugfix' but a 'new feature' and > asked me to revert, which I promptly did. > > I suspect that no new Zope 3.2.x release will come out soon anyway, so > maybe it doesn't make sense to add it there really, but it would be > really nice to have this feature available before the 3.3 release. > > Does anybody care about using eggs with Zope 3.2? I care about not adding this functionality in a stable release as I am totally unsure of how it will affect the Debian packaging of Zope. Debian packaging and eggs do not see eye to eye sometimes. > > -- > Sidnei da Silva > Enfold Systems, LLC. > http://enfoldsystems.com > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/jinty%40web.de > > -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Refresh / Change-Buttons
On Fri, Jan 27, 2006 at 06:58:02AM -0800, Alexander Limi wrote:
> On Fri, 27 Jan 2006 00:39:41 -0800, Michael Haubenwallner <[EMAIL PROTECTED]>
>
> wrote:
>
> > Christian Theune wrote:
> >
> >> On Fri, 2006-01-27 at 09:33 +0100, Michael Haubenwallner wrote:
> >>
> >>> 'Refresh' should be called 'Reset' -- in fact resetting the form
> >>> contents to the original loaded values
> >>> ('Reset' is also the buttons default value displayed in the browser)
> >> Well. That's not what the button currently does. When I click on it,
> >> it
> >> does a page reload. A form reset does this without.
> >> Then, I also don't see many 'reset' buttons nowadays. And I don't miss
> >> them. After all, I'm not sure in which order I would want them.
> >>
> >
> > Should have been resolved as by this Issue
> > http://www.zope.org/Collectors/Zope3-dev/467
>
> Good peoples!
>
> Please don't include the "Reset" functionality in HTML forms. It is
> absolutely useless, and is considered one of the classic usability
> mistakes. Just say no, kids!
+1
--
Brian Sutherland
Metropolis - "it's the first movie with a robot. And she's a woman.
And she's EVIL!!"
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] rdb: Disappearing Connection redux
On Thu, Feb 09, 2006 at 11:54:18AM +0100, Jan-Wijbrand Kolman wrote: > I add this implementation of isConnected to the mysqldbda in my setup > (Zope-2.9 + Five + sqlos, mysql 4.1.12) too, and things *seem* to have > improved. But not completely, every now and then I get the gone away > errors again. Make sure you have a sqlos revision after 22260, as before that sqlos was caching connections (even ones where the server has gone away). -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
