Re: [ZODB-Dev] make ZODB as small and compact as expected
Pretty sure this could be merged to zopefoundation project if anyone asked Carlos. On Tue, Jul 23, 2013 at 7:47 AM, Adam GROSZER agroszer...@gmail.com wrote: On 07/22/2013 01:27 PM, Jim Fulton wrote: - The biggest thing ZODB needs right now is documentation. Unfortunately, this isn't easy. There is zodb.org, but much better documentation is needed. There is https://github.com/cguardia/**ZODB-Documentationhttps://github.com/cguardia/ZODB-Documentation but seems like it got stalled 5 months ago. -- Best regards, Adam GROSZER -- Quote of the day: Each time you are honest and conduct yourself with honesty, a success force will drive you toward greater success. Each time you lie, even with a little white lie, there are strong forces pushing you toward failure. (Joseph Sugarman) __**_ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/**listinfo/zodb-devhttps://mail.zope.org/mailman/listinfo/zodb-dev -- Alan Runyan Skype/Twitter:: runyaga Office:: 713.942.2377 ext 111 http://ploud.com/ Plone site in less than 10 seconds ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On Mon, Jul 22, 2013 at 8:44 PM, Christian Tismer tis...@stackless.com wrote: Yes, I understand this intention and see no problem: Just the namespace might be ZODB.Btrees which would not change the split. They would still live alone, separate projects. This seems to be a complete red herring. What difference does the namespace make? from BTrees.IIBTree import IITree or from ZODB.BTrees.IIBTree import IITree That difference is completely insiginifant in all ways. But making that change would break all BTree usage in existence. I see no benefit in that change at all. //Lennart ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On 29.07.13 13:22, Lennart Regebro wrote: On Mon, Jul 22, 2013 at 8:44 PM, Christian Tismer tis...@stackless.com wrote: Yes, I understand this intention and see no problem: Just the namespace might be ZODB.Btrees which would not change the split. They would still live alone, separate projects. This seems to be a complete red herring. What difference does the namespace make? from BTrees.IIBTree import IITree or from ZODB.BTrees.IIBTree import IITree That difference is completely insiginifant in all ways. But making that change would break all BTree usage in existence. I see no benefit in that change at all. Interesting that nobody sees the problem. If you are always living in Zope world, your claim is understandable ;-) Here is the sketch of an example:: from durus.btree import BTree from BTrees.IIBTree import IITree # ... # now transform the one into the other... Here we have no problem because of two facts: - durus is packaged well, - BTrees luckily has the plural. There are other packages floating around, and I just like to work with many things installed together. But I agree it would be a bit harder to move it. I was confused and thought ZODB was already a namespace package. So let's cook the herring and have it for dinner -- Chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On Tue, Jul 23, 2013 at 3:47 AM, Adam GROSZER agroszer...@gmail.com wrote: On 07/22/2013 01:27 PM, Jim Fulton wrote: - The biggest thing ZODB needs right now is documentation. Unfortunately, this isn't easy. There is zodb.org, but much better documentation is needed. There is https://github.com/cguardia/**ZODB-Documentationhttps://github.com/cguardia/ZODB-Documentation but seems like it got stalled 5 months ago. Would be really great if it could be integrated with the zodb.org docs. Then a simple tutorial, a logo for zodb (something like a tree and pickles?) and a better theme for the read the docs and you got a great place for people to know of one of the secret weapons of the python world. :) -- Leonardo Santagada ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On Sun, Jul 21, 2013 at 12:12 AM, Christian Tismer tis...@stackless.com wrote: This is my last emission for tonight. I would be using ZODB as a nice little package if it was one. There should be nothing else but ZODB.some_package Instead, there is BTrees persistent transaction zc.lockfile zc.zlibstorage ZConfig zdaemon ZEO ZODB ZODB3 (zlibstorage) zope.interface and what I might have forgotton. Exception: There is also zodbpickle which I think is very usefull and general-purpose, and I wan to keep it, also I will try to push it into standard CPython. So, while all the packages are not really large, there are too many namespaces touched, and things like Zope Enterprize Objects are not meant to be here as open source pretending modules which the user never asked for. Despite it's tech-bubblishish acronym expansion, which few people are aware of, ZEO is the standard client-server component of ZODB, is widely used, and is certainly open source. I think these things could be re-packed into a common namespace and be made simpler. If ZODB had been born much later, it would certainly have used a namespace package. Now, it would be fairly disruptive to change it. Even zope.interface could be removed from this intended-to-be user-friendly simple package. I don't understand what you're saying. It's a dependency if ZODB. So while the amount of code is astonishingly small, the amount of abstraction layering tells the reader that this was never really meant to be small. And this makes average, simple-minded users like me shy away and go back to simpler modules like Durus. But the latter has serious other pitfalls, which made me want to re-package ZODB into something small, pretty, tool-ish, versatile thing for the pocket. Actually I'm trying to re-map ZOPE to the simplistic Durus interface, without its short-comings and lack of support. I think a successfully down-scaled, isolated package with ZODB's great implementation, but a more user-oriented interface would help ZODB a lot to get widely accepted and incorporated into very many projects. Right now people are just too much concerned of implicit complication which actually does not exist. I volunteer to start such a project. Proposing the name david, as opposed to goliath. ZODB is an old project that has accumulated some cruft over the years, however: - I've tried to simplify it and, with the exception of ZEO, I think it's pretty straightforward. - ZODB is used by a lot of people with varying needs and tastes. The fact that it is pretty modular has allowed a lot of useful customizations. - I'm pretty happy with the layered storage architecture. - With modern package installation tools like buildout and pip, having lots of dependencies shouldn't be a problem. ZODB uses lots of packages that have uses outside of ZODB. I consider this a strength, not a weakness. Honestly, I have no interest in catering to users who don't use buildout, or pip, or easy_install. - The biggest thing ZODB needs right now is documentation. Unfortunately, this isn't easy. There is zodb.org, but much better documentation is needed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On Sunday, July 21, 2013 06:12:34 AM Christian Tismer wrote: BTrees I agree, this could be part of ZODB and it would be fine. persistent transaction zc.lockfile zdaemon zope.interface These are all very useful outside the context of ZODB and I use them without it. zc.zlibstorage This is an add-on that I do not necessarily use, since I do not deal with large amounts of data. ZConfig In my opinion this is a relic from the times before configparser existed. It is also used by other projects outside of ZODB. ZEO This is separate for historical reasons. I agree it could be merged into the ZODB project these days. ZODB3 (zlibstorage) Well, this package is deprecated. It is available for backward-compatibility. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On Mon, Jul 22, 2013 at 9:15 AM, Stephan Richter stephan.rich...@gmail.com wrote: On Sunday, July 21, 2013 06:12:34 AM Christian Tismer wrote: ... ZConfig In my opinion this is a relic from the times before configparser existed. IMO, ZConfig is very useful in some specific cases, especially ZODB and logging configuration. It is also used by other projects outside of ZODB. ZEO This is separate for historical reasons. I agree it could be merged into the ZODB project these days. It was separate a long time ago. It's been part of the ZODB distribution for a long time until recently. It makes sense for it to be optional, as it's of no interest to people who use relstorage. More importantly, it's more complicated than any other part of ZODB and it makes a lot of sense for ZODB development to be unburdened of it. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On 22.07.13 15:15, Stephan Richter wrote: On Sunday, July 21, 2013 06:12:34 AM Christian Tismer wrote: BTrees I agree, this could be part of ZODB and it would be fine. ... ZODB3 (zlibstorage) Well, this package is deprecated. It is available for backward-compatibility. Yes, but I meant zlibstorage, which pulls ZODB3 in. I would like to put that as an optional package, but in ZODB (4) -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
On 22.07.13 18:01, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2013 09:15 AM, Stephan Richter wrote: BTrees I agree, this could be part of ZODB and it would be fine. Splitting out BTrees was a conscious decision to serve two goals: - - Allow evolving it (in particular, the work to port it to Py3k / PyPy) without stalling on the larger ZODB project. For ongoing work, it is useful to be able to release a fix for a BTrees-only bug without needing to release ZODB. - - Allow projects which use BTrees (as base classes or attributes) to be tested without needing to install all of ZODB. I consider both of those concerns still important, and so am -1 on re-absorbing BTrees into ZODB. Yes, I understand this intention and see no problem: Just the namespace might be ZODB.Btrees which would not change the split. They would still live alone, separate projects. This is just plugged in, like zlibstorage (if it were not ZODB3 ;-) ) Minor point, anyway ;-) -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] make ZODB as small and compact as expected
Am 22.07.2013 13:27, schrieb Jim Fulton: On Sun, Jul 21, 2013 at 12:12 AM, Christian Tismer tis...@stackless.com wrote: This is my last emission for tonight. I would be using ZODB as a nice little package if it was one. There should be nothing else but ZODB.some_package Instead, there is BTrees persistent transaction zc.lockfile zc.zlibstorage ZConfig zdaemon ZEO ZODB ZODB3 (zlibstorage) zope.interface and what I might have forgotton. Exception: There is also zodbpickle which I think is very usefull and general-purpose, and I wan to keep it, also I will try to push it into standard CPython. So, while all the packages are not really large, there are too many namespaces touched, and things like Zope Enterprize Objects are not meant to be here as open source pretending modules which the user never asked for. Despite it's tech-bubblishish acronym expansion, which few people are aware of, ZEO is the standard client-server component of ZODB, is widely used, and is certainly open source. I think these things could be re-packed into a common namespace and be made simpler. If ZODB had been born much later, it would certainly have used a namespace package. Now, it would be fairly disruptive to change it. Even zope.interface could be removed from this intended-to-be user-friendly simple package. I don't understand what you're saying. It's a dependency if ZODB. So while the amount of code is astonishingly small, the amount of abstraction layering tells the reader that this was never really meant to be small. And this makes average, simple-minded users like me shy away and go back to simpler modules like Durus. But the latter has serious other pitfalls, which made me want to re-package ZODB into something small, pretty, tool-ish, versatile thing for the pocket. Actually I'm trying to re-map ZOPE to the simplistic Durus interface, without its short-comings and lack of support. I think a successfully down-scaled, isolated package with ZODB's great implementation, but a more user-oriented interface would help ZODB a lot to get widely accepted and incorporated into very many projects. Right now people are just too much concerned of implicit complication which actually does not exist. I volunteer to start such a project. Proposing the name david, as opposed to goliath. ZODB is an old project that has accumulated some cruft over the years, however: - I've tried to simplify it and, with the exception of ZEO, I think it's pretty straightforward. - ZODB is used by a lot of people with varying needs and tastes. The fact that it is pretty modular has allowed a lot of useful customizations. - I'm pretty happy with the layered storage architecture. - With modern package installation tools like buildout and pip, having lots of dependencies shouldn't be a problem. ZODB uses lots of packages that have uses outside of ZODB. I consider this a strength, not a weakness. Honestly, I have no interest in catering to users who don't use buildout, or pip, or easy_install. - The biggest thing ZODB needs right now is documentation. Unfortunately, this isn't easy. There is zodb.org, but much better documentation is needed. Very much agreed. The most important thing to mention here is IMO the use of virtualenv which keeps your python installation's site packages clean. I don't mind if a certain package I need pulls in any number of dependencies, as the are resolved automagiaclly. @Chris: Maybe you could explain a bit more, why that bothers you? Which brings me to the second most important thing here: documentation. As you seem to be starting a new project using ZODB, maybe you could come up with a Getting started with ZODB in your own project or so which would (how I picture it) include a step by step walkthrough from zero to writing some simple Persistent classes and using them. That woul make your life easier in the long run as steps written down correctly tend to be very easy to reproduce. On the other hand the community would benefit from some neice peace of documentation. Is there a ZODB wiki (didn't find one), where we could gather this stuff? I've come accross a whole bunch of useful code snippets that a use seldomly but which are very, very useful then. For example how do i find/retrieve a object with oid 0xYYY?, How do I copy transactions starting whith tid xxx from one ZODB to another? I keep these in my private CMS, where they are obviously only useful to me. Time for a ZODB wiki?! Cheers! Jürgen Jim -- XLhost.de ® - Webhosting von supersmall bis eXtra Large XLhost.de GmbH Jürgen Herrmann, Geschäftsführer Boelckestrasse 21, 93051 Regensburg, Germany Geschäftsführer: Jürgen Herrmann Registriert unter: HRB9918 Umsatzsteuer-Identifikationsnummer: DE245931218 Fon: +49 (0)800 XLHOSTDE [0800 95467833] Fax: +49 (0)800 95467830 Web: http://www.XLhost.de
[ZODB-Dev] make ZODB as small and compact as expected
This is my last emission for tonight. I would be using ZODB as a nice little package if it was one. There should be nothing else but ZODB.some_package Instead, there is BTrees persistent transaction zc.lockfile zc.zlibstorage ZConfig zdaemon ZEO ZODB ZODB3 (zlibstorage) zope.interface and what I might have forgotton. Exception: There is also zodbpickle which I think is very usefull and general-purpose, and I wan to keep it, also I will try to push it into standard CPython. So, while all the packages are not really large, there are too many namespaces touched, and things like Zope Enterprize Objects are not meant to be here as open source pretending modules which the user never asked for. I think these things could be re-packed into a common namespace and be made simpler. Even zope.interface could be removed from this intended-to-be user-friendly simple package. So while the amount of code is astonishingly small, the amount of abstraction layering tells the reader that this was never really meant to be small. And this makes average, simple-minded users like me shy away and go back to simpler modules like Durus. But the latter has serious other pitfalls, which made me want to re-package ZODB into something small, pretty, tool-ish, versatile thing for the pocket. Actually I'm trying to re-map ZOPE to the simplistic Durus interface, without its short-comings and lack of support. I think a successfully down-scaled, isolated package with ZODB's great implementation, but a more user-oriented interface would help ZODB a lot to get widely accepted and incorporated into very many projects. Right now people are just too much concerned of implicit complication which actually does not exist. I volunteer to start such a project. Proposing the name david, as opposed to goliath. cheers -- chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
