Interest in "AdvancedQuery" and/or "ManagableIndex"?
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well. I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g. * my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me) * I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests * I use camel case also for parameters and local variables and not only for functions and "global" objects. Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions? -- Dieter
Dieter Maurer wrote:
I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation
That's great, thank you! :)
*BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
This is the only one that I find a bit difficult, because it means that if I were to fix a bug or make a change to the AQ/MI code, I would need to change my editor settings, and if I were making a simultaneous change to any other part of Zope, I'd have to have different settings in different buffers. I think it'd be silly if this was a show stopper, and I understand it'd be a pain to change every file, but how would you feel if someone else changed it for you and made it consistent with everything else?
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
You're not alone, and I can't imagine that would be a problem for anyone.
* I use camel case also for parameters and local variables and not only for functions and "global" objects.
Are we ever consistent on one or the other? Zope 2 specifically has camelCase all over the place. Anyone, +1 for inclusion or at least moving to svn.zope.org. Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
* I use camel case also for parameters and local variables and not only for functions and "global" objects.
Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions?
+1 from me. Tres - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFw7Pe+gerLs4ltQ4RApLxAJ91UBf1aePQYdJpOhOuFxZfRIqepACgxEF6 +qEijONxSeDNE5EMZldSIkw= =8sl4 -----END PGP SIGNATURE-----
--On 2. Februar 2007 22:36:37 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
+1
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
The source would have to be reformatted to fit at least in some way with the Zope standard :-) Any volunteers?
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
Unlikely a problem. Unit tests can not be replaced with doctests if you want to cover edge cases.
* I use camel case also for parameters and local variables and not only for functions and "global" objects.
No a problem (for me).
Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions?
No problem for importing the current state of your package on svn.zope.org. But we need a volunteer to integrate the packages for Zope 2.11. I think your code contains some ZCatalog monkeypatches...the related code has to be integrated properly. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting
Andreas Jung wrote at 2007-2-3 08:47 +0100:
...
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
The source would have to be reformatted to fit at least in some way with the Zope standard :-) Any volunteers?
If the code is reformatted, a new maintainer is necessary as well :-) -- Dieter
--On 4. Februar 2007 18:12:52 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2007-2-3 08:47 +0100:
...
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
The source would have to be reformatted to fit at least in some way with the Zope standard :-) Any volunteers?
If the code is reformatted, a new maintainer is necessary as well :-)
Anyone else should think about how to deal with this issue...I'm too much biased :-) Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
--On 4. Februar 2007 18:12:52 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2007-2-3 08:47 +0100:
...
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me) The source would have to be reformatted to fit at least in some way with the Zope standard :-) Any volunteers? If the code is reformatted, a new maintainer is necessary as well :-)
Anyone else should think about how to deal with this issue...I'm too much biased :-)
- -1 on reformatting code, especially if we are talking about putting it in 'repos/main/Products.{AdvancedQuery,ManageableIndex}': the win there is to have it *possible* for somebody elxe to submit patches, link the product in via 'svn:externals', etc., without making it harder for Dieter to maintain. $ python -c "import this" | grep purity Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFxnkp+gerLs4ltQ4RAqMZAKCCw+2pgtkIIuI/bDGeoZr6zkuKngCgnErD 4bficccORH5iDw7GRB1s5Lc= =kgrX -----END PGP SIGNATURE-----
--On 4. Februar 2007 19:24:09 -0500 Tres Seaver <tseaver@palladion.com> wrote:
Anyone else should think about how to deal with this issue...I'm too much biased :-)
- -1 on reformatting code, especially if we are talking about putting it in 'repos/main/Products.{AdvancedQuery,ManageableIndex}': the win there is to have it *possible* for somebody elxe to submit patches, link the product in via 'svn:externals', etc., without making it harder for Dieter to maintain.
The basic question for me is: should *any* code checked in on svn.zope.org follow the basic code styles like the 4 space rule or only code of the core component used for building releases? I think we have no law written down for this problem?! We all have a legitimate interest to see most of Dieters code in a public repository in order to use it properly for buildouts or for deploying it to sites. Someone of you might be interested to convince Dieter being more flexible and less meticulous.
$ python -c "import this" | grep purity
+1 on this but this applies always to both sides :-) Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2 Feb 2007, at 22:36, Dieter Maurer wrote:
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
That can be dealt with by reformatting. Should not be hard to quickly replace two spaces with four spaces everywhere.
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
I'm with you, I much prefer unit tests myself. doctests are not a requirement for items being put into svn.zope.org or into Zope 2. Thank god!
Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions?
+1 jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFxFLkRAx5nvEhZLIRAsQPAJoC8i9sgeoE0SnDmXVgjF1/VOi7/wCgoHEA G1PTS/P7hyfpwz1deM7YK10= =Q0Fd -----END PGP SIGNATURE-----
Hi Dieter! Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
* I use camel case also for parameters and local variables and not only for functions and "global" objects.
Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions?
These seem to be mature products with a lot of valuable code and documentation. I think the Zope Foundation should count itself lucky to get a donation like that. Unfortunately integrating a product into the Zope core means more than just adjusting the coding style: - As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core. - "There should be one-- and preferably only one --obvious way to do it." Do we really need two different query methods in the catalog? Two different FieldIndexes, KeywordIndexes and PathIndexes in the core? Or is there a way to merge them or to deprecate one? - ManagableIndex seems to resolve some cataloging issues in the Zope 2 TTW way that are resolved in Zope 3 using adapters. Isn't that a step in the wrong direction? - Should we add new products to the core? I thought we want to move away from products and use python packages instead. The AdvancedQuery code might become part of the ZCatalog package, ManagableIndex might be converted to a non-products package. Of course this is just my opinion. These are no official rules. Cheers, Yuppie
yuppie wrote:
- Should we add new products to the core? I thought we want to move away from products and use python packages instead. The AdvancedQuery code might become part of the ZCatalog package, ManagableIndex might be converted to a non-products package.
There are hardly "new", though, they've been around for ages and have enthusiastic users. Those users always found it hard to convince people to adopt them more widely because they were not in the standard repositories and a bit "scary" - I think any chance to resolve that should be taken. I'm quite bad for reshuffling code just for the sake of aesthetics, but I don't think having them as products should be any kind of barrier until products are officially deprecated (no, I didn't say that, let's not go there this decade). I think the first step is svn.zope.org. That makes them accessible for other people to work on. Shipping with Zope 2.x may or may not be a worthwhile goal in the short term - probably we need someone to cut a branch, see what it would look like and collectively review that. Martin
First let me say, that I'm in favour to add these products to Zope in some form, to take the chance to enhance the zcatalog significantly. Am 03.02.2007 um 14:34 schrieb Martin Aspeli:
yuppie wrote:
- Should we add new products to the core? I thought we want to move away from products and use python packages instead. The AdvancedQuery code might become part of the ZCatalog package, ManagableIndex might be converted to a non-products package.
There are hardly "new", though, they've been around for ages and have enthusiastic users. Those users always found it hard to convince people to adopt them more widely because they were not in the standard repositories and a bit "scary"
That's clearly a point to make clear, that splitting the code or to do big refactorings needs someone with deep knowledge of the code and its dependancy into the cataloging framework.
- I think any chance to resolve that should be taken. I'm quite bad for reshuffling code just for the sake of aesthetics, but I don't think having them as products should be any kind of barrier until products are officially deprecated (no, I didn't say that, let's not go there this decade).
+1
I think the first step is svn.zope.org. That makes them accessible for other people to work on. Shipping with Zope 2.x may or may not be a worthwhile goal in the short term - probably we need someone to cut a branch, see what it would look like and collectively review that.
Another point is that for example hurry is already using parts of the code. So there are possibilities to look for integration in zope3 too. With regards, __Janko -- Janko Hauser email: jhauser@zscout.de mobile: +49 1721 641552
Replying to my own post, Am 03.02.2007 um 15:14 schrieb Janko Hauser:
There are hardly "new", though, they've been around for ages and have enthusiastic users. Those users always found it hard to convince people to adopt them more widely because they were not in the standard repositories and a bit "scary"
That's clearly a point to make clear, that splitting the code or to do big refactorings needs someone with deep knowledge of the code and its dependancy into the cataloging framework.
What I wanted to express here is, that the inclusion as products is somewhat easier and more clearly defined, than to do a complete integration and restructuring of the whole index framework/code. So I propose to do this in two or more steps. With regards, __Janko
yuppie wrote at 2007-2-3 11:44 +0100:
... Unfortunately integrating a product into the Zope core means more than just adjusting the coding style:
- As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core.
"fixPluginIndexes" fixed (maybe meanwhile resolved) bugs in "Products.PluginIndexes.common.util.parseIndexRequest". The mentioned CMF monkey patch gives the "CatalogTool" the new method "evalAdvancedQuery", provided CMFCore is installed. I do not see why this monkey patch should not be applied. I am sure that I want to be able to use "AdvancedQuery" even with a "CatalogTool", if both are installed. -- Dieter
Dieter Maurer wrote:
yuppie wrote at 2007-2-3 11:44 +0100:
... Unfortunately integrating a product into the Zope core means more than just adjusting the coding style:
- As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core.
"fixPluginIndexes" fixed (maybe meanwhile resolved) bugs in "Products.PluginIndexes.common.util.parseIndexRequest".
The mentioned CMF monkey patch gives the "CatalogTool" the new method "evalAdvancedQuery", provided CMFCore is installed. I do not see why this monkey patch should not be applied.
I am sure that I want to be able to use "AdvancedQuery" even with a "CatalogTool", if both are installed.
Monkey patches should be avoided when they can. I think that's something we don't need to discuss. Integrating a product into Zope is the perfect opportunity to get rid of monkey patches and consolidate the fixes into the main product lines. Therefore, the CMF should rather grow that method itself than having it patched in by Zope. Either way, I think this point is mute since all the Plone community really wants is a public subversion repository with access to the code and "control over the code", which I would think is asking for a lot (you've indicated that reformatting the code would mean you wouldn't be available for maintenance anymore). Whoever is asking for AdvancedQuery and other things to be in svn.zope.org or even Zope 2 itself ought to weigh the amount of maintenance work against the little potential (not actual!) benefits. I think we can leave everything as it is and if Plone needs it in an svn repo, heck, why not do vendor imports? (not in svn.zope.org, of course, since the contributor agreement forbids that) -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
Philipp von Weitershausen wrote at 2007-2-4 18:35 +0100:
.... Monkey patches should be avoided when they can. I think that's something we don't need to discuss.
You think this way but I disagree... There are (potentially) dangerous monkey patches and harmless ones. We discuss about a harmless one: adding a new method when extended functionality is available. The monkey patch to CMFCore.CatalogTool.CatalogTool is necessary to ensure that "CatalogTool" searching (via "evalAdvancedQuery") behaves as usual for this tool (i.e. take View permission and validaty range into account).
Integrating a product into Zope is the perfect opportunity to get rid of monkey patches and consolidate the fixes into the main product lines. Therefore, the CMF should rather grow that method itself than having it patched in by Zope.
Only in case of a tight integration, i.e. when "ZCatalog" and "CMFCore.CatalogTool" can take for granted that "AdvancedQuery" is available. As I understand you, you are against tight integration of "AdvancedQuery". Even if tight integration should be opted for, I will fight for backward compatibility: the monkey patch will stay until both ZCatalog and the CMF have grown the new methods. -- Dieter
Philipp von Weitershausen wrote at 2007-2-4 18:35 +0100:
... I think we can leave everything as it is and if Plone needs it in an svn repo, heck, why not do vendor imports? (not in svn.zope.org, of course, since the contributor agreement forbids that)
One of the rare cases when I agree with Philipp: Let us keep things as they are. When Zope 2 is eggified (promissed for Zope 2.11), I will make the products available as eggs. People interested in a change history or in their own local changes can always put the products into a version control system. By the way, I heard about very few issues concerning these products, maybe 3 to 5, in their lifetime. Thus, I do not see why you (Plone people) want local changes. -- Dieter
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
yuppie wrote at 2007-2-3 11:44 +0100:
... Unfortunately integrating a product into the Zope core means more than just adjusting the coding style:
- As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core.
"fixPluginIndexes" fixed (maybe meanwhile resolved) bugs in "Products.PluginIndexes.common.util.parseIndexRequest".
The mentioned CMF monkey patch gives the "CatalogTool" the new method "evalAdvancedQuery", provided CMFCore is installed. I do not see why this monkey patch should not be applied.
I am sure that I want to be able to use "AdvancedQuery" even with a "CatalogTool", if both are installed.
Monkey patches should be avoided when they can. I think that's something we don't need to discuss. Integrating a product into Zope is the perfect opportunity to get rid of monkey patches and consolidate the fixes into the main product lines. Therefore, the CMF should rather grow that method itself than having it patched in by Zope.
Either way, I think this point is mute since all the Plone community really wants is a public subversion repository with access to the code and "control over the code", which I would think is asking for a lot (you've indicated that reformatting the code would mean you wouldn't be available for maintenance anymore).
Whoever is asking for AdvancedQuery and other things to be in svn.zope.org or even Zope 2 itself ought to weigh the amount of maintenance work against the little potential (not actual!) benefits. I think we can leave everything as it is and if Plone needs it in an svn repo, heck, why not do vendor imports? (not in svn.zope.org, of course, since the contributor agreement forbids that)
I'm not sure this warranted this much discussion or getting panties in a bunch, but maybe something was learned here. As phrased early on, it would be *nice* for those of us using svn:externals to manage certain build processes to have AdvancedQuery in svn somewhere(not life or death). did we reach some sort of conclusion in all this? Having a AQ egg would be the same difference imho. I would be happy to help maintain AdvancedQuery(though I hardly feel qualified), though I would prefer to leave it in a form that Dieter would actually want to work on it. What might be more worthwile is to package AQ up to be an egg(I volunteer for this). That way we could manage the dependency that way(zope could too if it chose to ship with AQ), dieter could continue maintaining AQ, and everything would be peachy. one last point re: Zope: From a marketing perspective(to parrot slinkp), I would think Zope 2 would want to include AdvancedQuery since it is a go-to answer for lots of "how do I do sqlish query X in the ZODB" type questions. Granted, hurry.query and the z3 catalogs have similar capabilities, but AQ works right now with existing z2 catalogs. -w -- ------ d. whit morriss ------ - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995
whit wrote at 2007-2-12 10:22 -0600:
... I'm not sure this warranted this much discussion or getting panties in a bunch, but maybe something was learned here. As phrased early on, it would be *nice* for those of us using svn:externals to manage certain build processes to have AdvancedQuery in svn somewhere(not life or death).
did we reach some sort of conclusion in all this?
You fetch it from my Zope page and put it into a subversion repository (perferably on a vendor branch) of your choice. -- Dieter
Previously Dieter Maurer wrote:
You fetch it from my Zope page and put it into a subversion repository (perferably on a vendor branch) of your choice.
Hanno imported it at http://svn.plone.org/svn/collective/AdvancedQuery two days ago. We'll try to keep that synchronised with your work. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Dieter Maurer wrote:
You fetch it from my Zope page and put it into a subversion repository (perferably on a vendor branch) of your choice.
Hanno imported it at http://svn.plone.org/svn/collective/AdvancedQuery two days ago. We'll try to keep that synchronised with your work.
Well that was Daniel Nouri, put otherwise you are right ;) Hanno
Previously Hanno Schlichting wrote:
Wichert Akkerman wrote:
Previously Dieter Maurer wrote:
You fetch it from my Zope page and put it into a subversion repository (perferably on a vendor branch) of your choice.
Hanno imported it at http://svn.plone.org/svn/collective/AdvancedQuery two days ago. We'll try to keep that synchronised with your work.
Well that was Daniel Nouri, put otherwise you are right ;)
That Hanno mask sure is popular :) Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Fri, Feb 02, 2007 at 10:36:37PM +0100, Dieter Maurer wrote:
I have no problems to donate "AdvancedQuery" and/or "Managable Index"
+1 from me. I haven't used Managable Index, but AdvancedQuery is great and more people should be aware of it.
to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
are you saying you would refuse the donation if somebody else wanted to change it to 4 spaces? -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2007-2-3 11:34 -0500:
...
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
are you saying you would refuse the donation if somebody else wanted to change it to 4 spaces?
Not, if he takes over the maintenance of the code as well. Code that I do not maintain need not comply with my personal style preferences.... -- Dieter
Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution.
I fail to find an explanation *why* that is.
According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
Again, why?
I have no problems to donate "AdvancedQuery" and/or "Managable Index" to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g.
* my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me)
* I much prefer unit tests over doctests; thus, "AdvancedQuery" and "Managable Index" come with extensive unit tests and no doctests
* I use camel case also for parameters and local variables and not only for functions and "global" objects.
Is there interest in "AdvancedQuery" and/or "Managable Index" to become part of the Zope 2 distribution under these conditions?
With that many +1 votes already, it might seem kinda pointless, but I'm -1. It's not a strong -1 but nevertheless a -1. Here's *why*: * I think Dieter is doing an excellent job at maintaining his products, why should that maintenance now become a burden of the Zope 2 maintainers? Why burden, you might ask? Because it's an "alien" product that is all of a sudden adopted into Zope. I'd think most of us aren't familiar with its code base, let alone being able to do bugfixes. If we adopt it into Zope core, we're bound to maintaining it forever, no matter what Dieter decides to do... * As Dieter outlines above, he prefers a few different styles. Code in svn.zope.org and *especially* code in Zope core should conform to a certain style. I'm not necessarily talking about doctests vs. unit tests, but a certain kind of code arrangement (and that includes developer-orienteded docs such as doctests nowadays) are appreciated. Why should we go thru the hassle of giving AdvancedQuery a do-over? I don't think anybody would appreciate all that work nor would Dieter probably appreciate his codebase to be changed (well, he *is* willing to donate this thing, so I'm sure he's ok with taking that risk, but still... is it really necessary?). * Plone is shipping with lots of products already, I don't see why it simply can't ship with another one. Seriously, why? Plus, if they're really trying to solve problems for Plone 3, then it seems to be too late already. The target platform, Zope 2.10, is feature-frozen since long. If this is all about Zope 2.11 and future release of Zope, I would like to direct your attention to one of my recent proposals, http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot, which I have plans for implementing in Zope 2.11. This propsal will allow us to package products like Dieter's excellent ones as Python Eggs and deploy them like any other package. So, if Plone really didn't want to ship with AdvancedQuery et. al., they could simply use the setuptools' dependency mechanism to at least depend on that egg. Hanno Schlichting has shown how powerful zc.buildout can be in this area with 'ploneout' already. It might not be a popular opinion in Zope 2 land where people would like to have as much working out of the box as possible, but I think we oughta think about making Zope 2 rather smaller than bigger (where "smaller" doesn't mean "ship with less stuff" but "have fewer inter-dependencies" so that it's better reusable). An Egg-based deployment mechanism with explicitly defined dependencies will allow us to do so. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution.
I fail to find an explanation *why* that is.
I'm not quite sure it has to be part of Zope 2 as you install it. Having it in svn.zope.org would go a long, way, though, allowing us to use svn:externals during development and potentially fix issues ourselves as appropriate.
According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
Again, why?
Probably similar reasoning as above. Note that Plone does not at this time depend on Managable Index, though I know some Plone developers who are enthusiastic about it.
* Plone is shipping with lots of products already, I don't see why it simply can't ship with another one. Seriously, why? Plus, if they're really trying to solve problems for Plone 3, then it seems to be too late already. The target platform, Zope 2.10, is feature-frozen since long.
We will ship with this. I think the original point that made us nervous is having to get tarballs from dieter.handshake.de, and not having a access to a repository. Whether it ships with Zope or not will probably depend on how valuable people find it. I've not used it myself, but it sounds like it makes the catalog a bit more powerful and usable.
It might not be a popular opinion in Zope 2 land where people would like to have as much working out of the box as possible, but I think we oughta think about making Zope 2 rather smaller than bigger (where "smaller" doesn't mean "ship with less stuff" but "have fewer inter-dependencies" so that it's better reusable). An Egg-based deployment mechanism with explicitly defined dependencies will allow us to do so.
I completely agree with this. On the other hand, as Andreas points out, if we are monkey patching ZCatalog to address deficiencies, then there may be reasons for tighter integration. I think the first step is to move it to the repository and let the community prod it a little. Martin
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution.
I fail to find an explanation *why* that is.
I'm not quite sure it has to be part of Zope 2 as you install it. Having it in svn.zope.org would go a long, way, though, allowing us to use svn:externals during development and potentially fix issues ourselves as appropriate.
Well, ok, I have nothing against that. It's just that that wasn't mentioned anywhere.
* Plone is shipping with lots of products already, I don't see why it simply can't ship with another one. Seriously, why? Plus, if they're really trying to solve problems for Plone 3, then it seems to be too late already. The target platform, Zope 2.10, is feature-frozen since long.
We will ship with this. I think the original point that made us nervous is having to get tarballs from dieter.handshake.de, and not having a access to a repository.
Whether it ships with Zope or not will probably depend on how valuable people find it. I've not used it myself, but it sounds like it makes the catalog a bit more powerful and usable.
Well, the Zope 3 catalog is pretty much useless w/o any extra packages either. But at this point it has become almost trivial to install the necessary packages such as zc.catalog into your instance (using easy_install or zc.buildout).
It might not be a popular opinion in Zope 2 land where people would like to have as much working out of the box as possible, but I think we oughta think about making Zope 2 rather smaller than bigger (where "smaller" doesn't mean "ship with less stuff" but "have fewer inter-dependencies" so that it's better reusable). An Egg-based deployment mechanism with explicitly defined dependencies will allow us to do so.
I completely agree with this. On the other hand, as Andreas points out, if we are monkey patching ZCatalog to address deficiencies, then there may be reasons for tighter integration.
Sure. Perhaps we can look at those deficiencies and sort those out first.
I think the first step is to move it to the repository and let the community prod it a little.
I'll be absolutely fine with that. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
Previously Martin Aspeli wrote:
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution.
I fail to find an explanation *why* that is.
I'm not quite sure it has to be part of Zope 2 as you install it. Having it in svn.zope.org would go a long, way, though, allowing us to use svn:externals during development and potentially fix issues ourselves as appropriate.
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Feb 2007, at 12:47, Wichert Akkerman wrote:
I'm not quite sure it has to be part of Zope 2 as you install it. Having it in svn.zope.org would go a long, way, though, allowing us to use svn:externals during development and potentially fix issues ourselves as appropriate.
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy.
I think it has been mentioned before, you have to contact Jim. No one outside of ZC is allowed to perform administration tasks that require root access on the box. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFxg2bRAx5nvEhZLIRAgsbAJ0fqkNK+ICKywSGSL72+8PmhD3/FQCgp9m8 zp6dPA3z2z1JYEX7heUuDco= =lHPM -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
On 4 Feb 2007, at 12:47, Wichert Akkerman wrote:
I'm not quite sure it has to be part of Zope 2 as you install it. Having it in svn.zope.org would go a long, way, though, allowing us to use svn:externals during development and potentially fix issues ourselves as appropriate.
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy.
I think it has been mentioned before, you have to contact Jim. No one outside of ZC is allowed to perform administration tasks that require root access on the box.
Oh. Since we have volunteers (like you :)), I wonder why the keys can't be turned over to the foundation by now? Can somebody from the board explain what the hold-up is and what we need to do open access to well established members of the community like Jens? -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Feb 2007, at 18:27, Philipp von Weitershausen wrote:
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy. I think it has been mentioned before, you have to contact Jim. No one outside of ZC is allowed to perform administration tasks that require root access on the box.
Oh. Since we have volunteers (like you :)), I wonder why the keys can't be turned over to the foundation by now? Can somebody from the board explain what the hold-up is and what we need to do open access to well established members of the community like Jens?
ZC company policy has changed, it used to be lenient, it no longer is. My take on it right now is this: If I'm required to beg anyone at ZC or chase people at ZC down myself to make this happen I am un- volunteering. I care, but not that much anymore. I'm willing to help, but I won't jump through arbitrary hoops in order to do so. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFxhpKRAx5nvEhZLIRAnCHAJ46Fs6+nsJB7tnPxVKDCptYqXCabACcDuXU LvR2lIpVfZqN/7REHFGDzj0= =nMg+ -----END PGP SIGNATURE-----
--On 4. Februar 2007 18:39:22 +0100 Jens Vagelpohl <jens@dataflake.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4 Feb 2007, at 18:27, Philipp von Weitershausen wrote:
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy. I think it has been mentioned before, you have to contact Jim. No one outside of ZC is allowed to perform administration tasks that require root access on the box.
Oh. Since we have volunteers (like you :)), I wonder why the keys can't be turned over to the foundation by now? Can somebody from the board explain what the hold-up is and what we need to do open access to well established members of the community like Jens?
ZC company policy has changed, it used to be lenient, it no longer is.
My take on it right now is this: If I'm required to beg anyone at ZC or chase people at ZC down myself to make this happen I am un-volunteering. I care, but not that much anymore. I'm willing to help, but I won't jump through arbitrary hoops in order to do so.
No reason more to enfore the handover of the remaining responsibilities from ZC to the Zope Foundation. We should discuss that on the foundation list. Andreas
--On 4. Februar 2007 18:44:38 +0100 Andreas Jung <lists@zopyx.com> wrote:
--On 4. Februar 2007 18:39:22 +0100 Jens Vagelpohl <jens@dataflake.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4 Feb 2007, at 18:27, Philipp von Weitershausen wrote:
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy. I think it has been mentioned before, you have to contact Jim. No one outside of ZC is allowed to perform administration tasks that require root access on the box.
Oh. Since we have volunteers (like you :)), I wonder why the keys can't be turned over to the foundation by now? Can somebody from the board explain what the hold-up is and what we need to do open access to well established members of the community like Jens?
ZC company policy has changed, it used to be lenient, it no longer is.
My take on it right now is this: If I'm required to beg anyone at ZC or chase people at ZC down myself to make this happen I am un-volunteering. I care, but not that much anymore. I'm willing to help, but I won't jump through arbitrary hoops in order to do so.
No reason more to enfore the handover of the remaining responsibilities from ZC to the Zope Foundation. We should discuss that on the foundation list.
Should be "One more reason...." Andreas
Previously Wichert Akkerman wrote:
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy.
I asked Jim about this and he told me to just import the current CVS code into svn and go from there, keeping history only in CVS. So I just did just that: ZopeVersionControl can now be found at svn+ssh://svn.zope.org/repos/main/Products.ZopeVersionControl . I don't have CVS commit access so I can't stick a note in CVS HEAD to indicate this move. Can someone please add that? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
Previously Wichert Akkerman wrote:
Note that we have the same issue with ZopeVersionControl, which is currently only in CVS. An import of that into subversion would make a lot of us very happy.
I asked Jim about this and he told me to just import the current CVS code into svn and go from there, keeping history only in CVS.
So I just did just that: ZopeVersionControl can now be found at svn+ssh://svn.zope.org/repos/main/Products.ZopeVersionControl .
I don't have CVS commit access so I can't stick a note in CVS HEAD to indicate this move. Can someone please add that?
I looked at my CVS checkout, and noticed that a file ('tests/common.py') had not been checked in for ZVC 0.3.3. I therefore checked it in, tagged 0.3.4, and re-imported the SVN version from that tag. Finally, I added an 'ATTENTION_THIS_AREA_IS_NOW_CLOSED.txt' file and 'cvs rm'ed the remaining files from the CVS trunk. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFx2bs+gerLs4ltQ4RAnQzAKCMpJMTJDQiyWQdVG5u5mYVRZOtSgCgmQ8D 114VYDDKPDdJXdezf3wTlNU= =2m5u -----END PGP SIGNATURE-----
Previously Tres Seaver wrote:
I looked at my CVS checkout, and noticed that a file ('tests/common.py') had not been checked in for ZVC 0.3.3. I therefore checked it in, tagged 0.3.4, and re-imported the SVN version from that tag. Finally, I added an 'ATTENTION_THIS_AREA_IS_NOW_CLOSED.txt' file and 'cvs rm'ed the remaining files from the CVS trunk.
Thanks for catching and fixing that! Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Previously Dieter Maurer wrote:
Whit ("mailto:d.w.morriss@gmail.com") reported that "AdvancedQuery" is going to ship with Plone3 and that packaging would be easier for them if "AdvancedQuery" were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have "Managable Index" in the Zope 2 distribution, as well.
Plone 3 indeed depends on AdvancedQuery now. Since we manage Plone development via subversion bundles (and must people I know of do the same thing for their development environments) it would make things a lot simpler for us if all products and packages we use can be linked using svn externals. Currently AdvancedQuery is the only one where we can not do that, hence the desire to have it in svn.zope.org as well. Having AdvancedQuery be part of the Zope 2 distribution or core is not relevant for us. AdvancedQuery certainly has some features that would be very nice to have included in Zope 2, but that is a different discussion and something that will require a lot more thought and work. Are there any objections to Dieter donating AdvancedQuery to the Zope Foundation and moving it to svn.zope.org, but keeping him as maintainer of the product? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
participants (12)
-
Andreas Jung -
Dieter Maurer -
Hanno Schlichting -
Janko Hauser -
Jens Vagelpohl -
Martin Aspeli -
Paul Winkler -
Philipp von Weitershausen -
Tres Seaver -
whit -
Wichert Akkerman -
yuppie