[Zope-dev] ZTK policy and package list (was Re: List of packages in the ZTK)
I've created a policy draft as well as an initial list of packages on a wiki page, which I hope will help us to collaborate on the list: http://wiki.zope.org/zope3/ZTK I've put into the list the packages that I'd consider part of the ZTK and that I use in my applications. I don't know anything about grok and I doN't have a list of ZTK libraries used by zope2 or repoze. I'd like to ask help from everybody who cares about the ZTK to enhance the list adding the packages that they use, their zope.org username in the list of the developers for the package they are willing to maintain and the framework which are consumers of the libraries. IMHO, it is easier to get a real list if we start from an empty one and we add packages instead of starting from a huge list removing packages. Thanks, Fabio * 2009-08-06 23:56, Wichert Akkerman wrote: This sounds like the right starting point to me. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-02 18:34]: 2. Some of the tests only pass if run separately, due to test interactions. Presumably, this means that other tests aren't cleaning up after themselves. I think we need a standard automated way to run each package's tests separately. I think some folks are working on that. I've just released z3c.recipe.compattest-0.6, which can now populate the list of packages to run test for from a buildout section, which makes it easy to test against a KGS. So, if you're developing zope.foo, you can set up your buildout.cfg like this: [buildout] develop = . parts = whatever else you need compat extends = http://url/to/kgs/versions.cfg # assuming said versions.cfg uses a section called [versions]: versions = versions [versions] # use development version of our package zope.foo = [compat] recipe = z3c.recipe.compattest and then run bin/test-compat to run the tests of each package in versions against the development version of zope.foo (in a separate process). So this means that if someone modifies a package that is in the KGS, they need to run the KGS tests before checking in. After we reach a consensus on how to do it (I'm in favor of the way outlined above, of course ;-), I'd like to add a step-by-step walkthrough of the day-to-day development of a package somewhere below http://docs.zope.org/zopetoolkit/process/index.html, which would include a description of how to run KGS tests. Regarding the KGS, I have a question: Where is the current KGS and how do we update it? By where is I mean the location of the versions.cfg, by current I mean the trunk, the version currently in development, the version where we probably want to bump the version number of a package as soon as a version is released, and by update I mean that I'd like this operation to involve no manual interaction other than committing the new version number to SVN. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
Hello Wolfgang, * 2009-08-07 11:42, Wolfgang Schnerring wrote: [buildout] develop = . parts = whatever else you need compat extends = http://url/to/kgs/versions.cfg # assuming said versions.cfg uses a section called [versions]: versions = versions I've done something similar in z3c.recipe.kgs (which is a fork of compattest, I did not want to commit anything there, but I'm more than happy to bring back my changes). The KGS is defined here: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg IMHO the KGS testing should be done using the controlled-packages.cfg and not versions, because some of the packages in the KGS are marked as not to be tested. Regarding the KGS, I have a question: Where is the current KGS and how do we update it? By where is I mean the location of the versions.cfg, AFAICK, It can be built from zope.release. and by update I mean that I'd like this operation to involve no manual interaction other than committing the new version number to SVN. I suppose there is no policy (yet) regarding how we manage the KGS. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
Thanks Fabio and Wolfgang, How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. (Note that I'm using more precise jargon: project rather than package. In the Python world, the word package means a module that is implemented as a directory rather than a file. A project is a collection of software for which we create distributions. We should generally be using the word project rather than package.) Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
Hello Jim, * 2009-08-07 12:28, Jim Fulton wrote: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. In my recipe, it automatically tests all the libraries that are marked as tested=true in the controlled-packages.cfg, but you can filter and test only a subset of those packages, for example: [test-kgs] recipe = z3c.recipe.kgs kgs = http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg packages = zope.component zope.interface zope.event zope.configuration If somebody tells me how it is possible to get projects from the controlled-packages.cfg using zope.kgs, I can modify the recipe code to understand it. :) -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
2009/8/7 Fabio Tranchitella kob...@kobold.it: Hello Jim, * 2009-08-07 12:28, Jim Fulton wrote: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. In my recipe, it automatically tests all the libraries that are marked as tested=true in the controlled-packages.cfg, Ah cool, so you don't just use the versions section. Wolfgang? Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-07 06:01]: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. With z3c.recipe.compattest, to build the list of projects to run tests for you can at the moment: - specify project names to include - specify buildout section names whose keys will be included (and it defaults to the [versions] section for ease of use) - specify regexes to remove entries from the included list So if your [versions] section contains projects you don't want to run tests for, I guess you either need to exclude those explicitly, or not feed this section to compattest in the first place and build up the include list in a different way instead. Could you elaborate what use case you are envisioning here? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-07 12:39]: 2009/8/7 Fabio Tranchitella kob...@kobold.it: * 2009-08-07 12:28, Jim Fulton wrote: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. In my recipe, it automatically tests all the libraries that are marked as tested=true in the controlled-packages.cfg, Ah cool, so you don't just use the versions section. Wolfgang? My guideline was let's rely on buildout rather than let's use zope.kgs or anything else rather specific. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
* Fabio Tranchitella kob...@kobold.it [2009-08-07 11:46]: * 2009-08-07 11:42, Wolfgang Schnerring wrote: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg IMHO the KGS testing should be done using the controlled-packages.cfg and not versions, because some of the packages in the KGS are marked as not to be tested. If controlled-packages.cfg is to be the authoritative represenation of the KGS (and maybe it should be, since it contains more information than versions.cfg) then I'd probably wish for a buildout recipe that can pin versions based on that data format, because I much prefer less moving parts. In other words, I would very much like a single gesture to tell buildout use this KGS: extends=something-or-other.cfg. The rest should Just Work(tm). - Less compiling. Having to explicitly regenerate versions.cfg feels superfluous - While developing something, you probably want to change the KGS from the official one to a local one, having to remember to change both the versions.cfg and the packages.cfg for the compattests is error prone. Regarding the KGS, I have a question: Where is the current KGS and how do we update it? By where is I mean the location of the versions.cfg, AFAICK, It can be built from zope.release. Right. But it's not publicly accessible. (And uploading to say download.zope.org is restricted to people with access there) But if versions.cfg is not to be the authoritative representation of the KGS then my point here is moot. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
On Fri, Aug 7, 2009 at 6:52 AM, Wolfgang Schnerringw...@gocept.com wrote: * Jim Fulton j...@zope.com [2009-08-07 06:01]: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. With z3c.recipe.compattest, to build the list of projects to run tests for you can at the moment: - specify project names to include - specify buildout section names whose keys will be included (and it defaults to the [versions] section for ease of use) - specify regexes to remove entries from the included list So if your [versions] section contains projects you don't want to run tests for, I guess you either need to exclude those explicitly, or not feed this section to compattest in the first place and build up the include list in a different way instead. Could you elaborate what use case you are envisioning here? Yes, although I'll note that this was discussed here just yesterday. We have a set of projects we want to run tests for. We want the tests to be as reproducible as possible, so we want to control what can cause changes in test outcome, and so that we have a working configuration that applications using the projects can use as a starting point. For this reason, we specify the versions of all projects we test *and* all projects those projects depend on. We may not test all of the dependencies for various reasons, but we still want to fix the versions of the dependencies. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 3 OK, 4 Failed
Summary of messages to the zope-tests list. Period Thu Aug 6 12:00:00 2009 UTC to Fri Aug 7 12:00:00 2009 UTC. There were 7 messages: 7 from Zope Tests. Test failures - Subject: FAILED (failures=1) : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 6 20:59:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012241.html Subject: FAILED (failures=1) : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 6 21:03:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012243.html Subject: FAILED (failures=1) : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 6 21:05:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012244.html Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Thu Aug 6 21:07:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012245.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 6 20:53:26 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012239.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 6 20:57:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012240.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Aug 6 21:01:27 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012242.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Mon, Aug 3, 2009 at 08:04, Martijn Pieters m...@zopatista.com wrote: AssertionError: Incorrect Content-Length is set! Expected 20425, got 20426. I don't grok the range support code at all: probably Martijn Pieters is the only person in the world who does. The tests are quite obscure to me, so I can't diagnose even whether the failure is a testing artifact or a real bug. Here's my response to Tres; for some reason my mail reader didn't include zope-dev. I can add now that I'll be at a sprint this weekend where I'll probably have time to take a look myself: I have found the problem, but do not understand where exactly the error occurs. The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. Further datapoints, the following extra lines for the above script give more context to compare: import sys print slicer[sys.maxint:] print slicer[sys.maxint-1:] print Slicer()[1:] So we pass in sys.maxint and sys.maxint-1 as start values, and also run the Slicer without acquisition wrapping to demonstrate that the wrapper is the culprit, not python itself. Python passes in sys.maxint for the end value for the slice if you omit it, and these high values overflow somewhere in the wraper. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Optional integration need not introduce dependencies
In discussing dependencies, as we try to clean up dependencies of Zope (especially ZTK) projects, I've noticed a pattern that I think deserves some special handling. Often, a module (including a ZCML file) within a project provides an implementation of an interface defined by an external package or an adapter of a class or interface defined in the external package. If the module is optional and exists solely to integrate with the external API, then the external project need not be a dependency. Why? Because an application won't use this module unless it already uses the external project. For example, lots of projects provide publisher views or zcml configuration directives. As long as these are in optional modules or ZCML files, then dependencies on zope.publisher or zope.configuration aren't necessary, as no one will use these modules or zcml files unless they're already using zope.publisher or zope.configuration. Again, this assumes that these modules are optional. For example, if a project's configuration file, configure.zcml registers views or includes a configuration file that registers views, then the dependency on zope.publisher is not optional. Let's look at a more specific example. zope.app.publisher provides some xmlrpc view registrations for zope.container in xmlrpc/configure.zcml. If the xmlrpc module was optional, or if these container registrations were conditedl [1]_ on zope.container having been installed, then zope.app.publisher wouldn't need to depend on zope.container [2]_. As it stands though, one can't include the main configuration for zope.app.publisher without also configuring the container xmlrpc views, so zope.container is required. Jim .. [1] We can make these registrations conditional on zope.container like this: configure condition=installed zope.container view for=zope.container.interfaces.IItemContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ItemTraverser permission=zope.Public / view for=zope.container.interfaces.IReadContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ContainerTraverser permission=zope.Public / /configure .. [2] This assumes we could get rid of the zope.container import in browser/tests/test_directoryresource, which I strongly suspect we can.) -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? The following checkin fixed this particular problem: http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102564view=rev The acquisition slice wrapper accepted Py_ssize_t arguments, but then passed these of as C ints (format string 'i'). Changing the format string to 'n' (Py_ssize_t) fixed *this particular case*. Likely more such fixes must be made. In any case, the HTTP range test no longer fails with this fix. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying dependencies of zope.app.publisher
2009/7/8 Fabio Tranchitella kob...@kobold.it: Hello, I'm sorry if I am flooding the list with all my requests/messages, but I don't want to introduce changes without approval of more experienced zope developers. I was analyzing zope.app.publisher, and I found that it would be possible to remove its dependency on zope.container because the latter is only used in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like this: view for=zope.container.interfaces.IItemContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ItemTraverser permission=zope.Public / I think these snippets should me moved to zope.container's configure.zcml, where we already have other traversers. Do you agree with this change? Nope. (well, maybe in the long term) :) For now, make these registrations conditional on the installation of zope.container and then get rid of the dependency. See the other note I sent earlier today on optional dependencies. You'll also need to sort out the test dependency in browser/test_directoryresource. I expect that that dependency is spurious. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Optional integration need not introduce dependencies
Hi Jim Betreff: [Zope-dev] Optional integration need not introduce dependencies In discussing dependencies, as we try to clean up dependencies of Zope (especially ZTK) projects, I've noticed a pattern that I think deserves some special handling. Often, a module (including a ZCML file) within a project provides an implementation of an interface defined by an external package or an adapter of a class or interface defined in the external package. If the module is optional and exists solely to integrate with the external API, then the external project need not be a dependency. Why? Because an application won't use this module unless it already uses the external project. For example, lots of projects provide publisher views or zcml configuration directives. As long as these are in optional modules or ZCML files, then dependencies on zope.publisher or zope.configuration aren't necessary, as no one will use these modules or zcml files unless they're already using zope.publisher or zope.configuration. Again, this assumes that these modules are optional. For example, if a project's configuration file, configure.zcml registers views or includes a configuration file that registers views, then the dependency on zope.publisher is not optional. Let's look at a more specific example. zope.app.publisher provides some xmlrpc view registrations for zope.container in xmlrpc/configure.zcml. If the xmlrpc module was optional, or if these container registrations were conditedl [1]_ on zope.container having been installed, then zope.app.publisher wouldn't need to depend on zope.container [2]_. As it stands though, one can't include the main configuration for zope.app.publisher without also configuring the container xmlrpc views, so zope.container is required. Jim .. [1] We can make these registrations conditional on zope.container like this: configure condition=installed zope.container view for=zope.container.interfaces.IItemContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ItemTraverser permission=zope.Public / view for=zope.container.interfaces.IReadContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ContainerTraverser permission=zope.Public / /configure .. [2] This assumes we could get rid of the zope.container import in browser/tests/test_directoryresource, which I strongly suspect we can.) I think XML-RPC just belongs to an own package e.g. zope.xmlrpc. It doesn't make sense to have XML-RPC in a package other then an own. If we move the XML-RPC part out of other packages, then we have the question should the zope.xmlrpc package depend on IContainer? Probably not and the new zope.xmlrpc package should use your suggested conditional configuration. Such an own zope.xmlrpc package whould depend on the publisher as much as the XML-RPC implementation does. This allows to use a custom XML-RPC implementation based on something else then the publisher concept. (custom xmlrpc package) Does this make sense? btw, I think XML-RPC should be an optional package like z3c.jsonrpc. The same belongs to FTP and WebDav support. (Not sure if WebDav is optional, at least FTP is optional configurable at zope.conf level) Regards Roger Ineichen -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying dependencies of zope.app.publisher
On Thu, Aug 6, 2009 at 4:39 PM, Shane Hathawaysh...@hathawaymix.org wrote: ... I'm hoping Jim will soon take charge of zope.publisher, zope.traversing, zope.container, and zope.app.publisher, because he seems to be the only one who knows how they are supposed to be related. Hah. Thanks a lot. ;) Things have moved around so much over the last couple of years I'm not sure anyone knows where things belong any more. ;) I do have some ideas for some specific minor cleanups in some of these. (That had to do with zope.app.publication, not zope.app.publisher.) That was blocked by the general instability we have right now. I'd really like us to stop moving things around until we get to a point where we have a reasonable kgs that has tests passing in Python 2.4-2.6 and on at least linux and mac. Once we have that and the processes in place to keep it, we can start to make progress again. I also have some ideas about how people should use zope.publisher (see the in progress, though stalled, zc.publication). Again, once we reach some stability, I can make progress on that again. For example, which packages should be aware of XML-RPC? I would guess that none of them should have any notion of XML-RPC, and that there should be a zope.xmlrpc package, but my confidence in that guess is very low. I'd really like to deprecate our current approach to XMLRPC. It's way too complicated. In the mean time, I'd like to find ways to make it more optional than it is now. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] XMLRPC support (was Re: Optional integration need not introduce dependencies)
On Fri, Aug 7, 2009 at 10:51 AM, Roger Ineichend...@projekt01.ch wrote: ... I think XML-RPC just belongs to an own package e.g. zope.xmlrpc. It doesn't make sense to have XML-RPC in a package other then an own. Agreed, although moving it out would introduce a backward incompatibility. Maybe there's a way to finesse this or maybe we just bump the major version # of zope.publisher. BTW, I don't think the approach we took (I helped :) for XMLRPC turned out well. Given ajax and json, I don't really care about xmlrpc any more, but if I did, I'd want to take a much lighter weight and more localized approach. If we move the XML-RPC part out of other packages, then we have the question should the zope.xmlrpc package depend on IContainer? Probably not and the new zope.xmlrpc package should use your suggested conditional configuration. Yup Such an own zope.xmlrpc package whould depend on the publisher as much as the XML-RPC implementation does. This allows to use a custom XML-RPC implementation based on something else then the publisher concept. (custom xmlrpc package) Does this make sense? Yes, except that I don't really care about xmlrpc and If I did, I'd take a different approach. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabio Tranchitella wrote: Hello, * 2009-08-07 05:28, Fred Drake wrote: In particular, I would exclude any package in the zope.app.* namespace which is not also used by either grok or Zope2. As would I. Fine, I plan to work on this today, building the dependency graph of zope2, zope3 and grok and cherry picking the right list. Do you know how am I supposed to get the list of packages used by Zope2? http://svn.zope.org/*checkout*/Zope/trunk/versions.cfg?view=markup Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKfESe+gerLs4ltQ4RAtJMAJ4/ySCHQhc7mQIgyZn02JQtehJ1sgCfSGzD lepZKaTOiP7/ILAz8gvX8E8= =9gfR -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying dependencies of zope.app.publisher
2009/8/7 Fabio Tranchitella fa...@tranchitella.it: Hey Jim, you picked up an old e-mail of mine (it is from 8th of July)! :) I know, but I thought my response was most applicable to the original. :) * 2009-08-07 17:13, Jim Fulton wrote: For now, make these registrations conditional on the installation of zope.container and then get rid of the dependency. I like your approach about optional dependencies, and IIRC I already proposed something like this on the list. Cool. :) I think although that it is not safe to make any change until we get a clean, tested, explicit and globally accepted KGS for the ZTK. This is my top priority right now. :) That makes me happy. :) Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[ZWeb] IOError: [Errno 28] No space left on device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, disk is full again. Last successful transaction was at 2009-08-07 12:50:24 AM systemtime. Regards Michael - -- http://blog.d2m.at http://planetzope.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKe8t7l0uAvQJUKVYRAimfAJ9otDgdqyKkKq5NHynvq8r33+iB4QCguO32 eGQ5Ubc7zc6fLa8NLT6DhzM= =OuuH -END PGP SIGNATURE- ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] IOError: [Errno 28] No space left on device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 7, 2009, at 08:36 , Michael Haubenwallner wrote: Hi, disk is full again. Last successful transaction was at 2009-08-07 12:50:24 AM systemtime. As predicted, the disk was full when the pack process finished. I'm surprised it did finish at all. I deleted the Data.fs.old file. @Jim: the automated pack apparently does not pack to 0 days. Someone will have to do this manually to get a smaller ZODB. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp74t0ACgkQRAx5nvEhZLJA5ACeJahNKZlVu51+D+EEcSwDUUqR gOoAn34HwfDCELg34sdcIUx2iT1/boZI =0zgc -END PGP SIGNATURE- ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] IOError: [Errno 28] No space left on device
On Fri, Aug 7, 2009 at 4:16 AM, Jens Vagelpohlj...@dataflake.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 7, 2009, at 08:36 , Michael Haubenwallner wrote: Hi, disk is full again. Last successful transaction was at 2009-08-07 12:50:24 AM systemtime. As predicted, the disk was full when the pack process finished. I'm surprised it did finish at all. I guess we got lucky. I deleted the Data.fs.old file. Thanks. @Jim: the automated pack apparently does not pack to 0 days. Someone will have to do this manually to get a smaller ZODB. We're going to replace the hardware, and when we do, we'll have a much larger disk. I think we have enough disk space for now as long as we don't pack. Jim -- Jim Fulton ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] IOError: [Errno 28] No space left on device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 7, 2009, at 11:52 , Jim Fulton wrote: We're going to replace the hardware, and when we do, we'll have a much larger disk. I think we have enough disk space for now as long as we don't pack. Who is making sure that any automated pack cron jobs are turned off? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp8JPIACgkQRAx5nvEhZLLSGQCfZE+s+ZN+ypBOi4+2U3uuXaCX GjkAoILRa8rMFpij1YW1k1kfyUsvR+eK =7uRY -END PGP SIGNATURE- ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] IOError: [Errno 28] No space left on device
On Fri, Aug 7, 2009 at 8:58 AM, Jens Vagelpohlj...@dataflake.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 7, 2009, at 11:52 , Jim Fulton wrote: We're going to replace the hardware, and when we do, we'll have a much larger disk. I think we have enough disk space for now as long as we don't pack. Who is making sure that any automated pack cron jobs are turned off? We already did. Jim -- Jim Fulton ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
[Zope] acl_users and encrypted passwords
When you encrypt your passwords in an acl_users User Folder, is there a way to check that the old password is correct? I'm building an app that allows the user to change her password with the usual form of: Old: New: Confirm: -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com fun crosstips.org ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] acl_users and encrypted passwords
On 07.08.09 16:26, Peter Bengtsson wrote: When you encrypt your passwords in an acl_users User Folder, is there a way to check that the old password is correct? I'm building an app that allows the user to change her password with the usual form of: Old: New: Confirm: You has the 'old' password using the same algorithm and compare it against the stored password hash. Look the AccessControl API of Zope. -aj begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] acl_users and encrypted passwords
No, it's different every time.
Consider this::
def _doAddUser(self, name, password, roles, domains, **kw):
Create a new user
...
if password is not None and self.encrypt_passwords:
print \tself._encryptPassword('word')=,
repr(self._encryptPassword('word'))
print \tself._encryptPassword('word')=,
repr(self._encryptPassword('word'))
print \tself._encryptPassword('word')=,
repr(self._encryptPassword('word'))
When running this you get this output::
self._encryptPassword('word')=
'{SSHA}dxZSdvO5CiaMbDuCC0mAreI0R6nqc5RyYFGo'
self._encryptPassword('word')=
'{SSHA}pup1PWzONwMnGXk/itXd6rhySF8MOuI57SO6'
self._encryptPassword('word')=
'{SSHA}HGRxMfi9J7uGK8tfHvuMWfIbNghvu+Z2hb7a'
2009/8/7 Andreas Jung li...@zopyx.com:
On 07.08.09 16:26, Peter Bengtsson wrote:
When you encrypt your passwords in an acl_users User Folder, is there
a way to check that the old password is correct?
I'm building an app that allows the user to change her password with
the usual form of:
Old:
New:
Confirm:
You has the 'old' password using the same algorithm and compare it
against the stored password hash. Look the AccessControl API of Zope.
-aj
___
Zope maillist - z...@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
fun crosstips.org
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] acl_users and encrypted passwords
On 07.08.09 17:10, Peter Bengtsson wrote: No, it's different every time. Using private methods is unlikely the road to success. There is some official method with *validate* or something similar.. In addition: if you call the low-level methods blindly, you must take the 'salt' into account. -aj begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] acl_users and encrypted passwords
On 07.08.09 17:22, Andreas Jung wrote: On 07.08.09 17:10, Peter Bengtsson wrote: No, it's different every time. Using private methods is unlikely the road to success. There is some official method with *validate* or something similar.. In addition: if you call the low-level methods blindly, you must take the 'salt' into account. AuthEncoding.pw_validate() is likely what you are searching for. -aj begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] acl_users and encrypted passwords
2009/8/7 Andreas Jung li...@zopyx.com: On 07.08.09 17:22, Andreas Jung wrote: On 07.08.09 17:10, Peter Bengtsson wrote: No, it's different every time. Using private methods is unlikely the road to success. There is some official method with *validate* or something similar.. In addition: if you call the low-level methods blindly, you must take the 'salt' into account. AuthEncoding.pw_validate() is likely what you are searching for. That was the one! THanks for the tip -aj ___ Zope maillist - z...@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com fun crosstips.org ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
