...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> What do people think about including bsddb3 in Python 2.3, MvL> along with deprecating the existing bsddb module? You'll find MvL> the package at MvL> http://pybsddb.sourceforge.net/ +1, for several reasons. - Robin's done a great job with the module. It feels quite solid and reliable. I've used it quite a bit working on Berkeley storage for ZODB/Zope. - Berkeley support in 2.2 is broken -- at least the setup.py rules are. On my stock, but stocked Mandrake 8.1 system, bsddbmodule never links right and the standard setup.py always deletes it because oflink problems. Fixing this is on My List, although I'd prefer to work with pybsddb. - I've talked to the Sleepycat guys, and if we wanted to, we could provide the Berkeley libraries with our distros with no licensing problems. Using Berkeley through the pybsddb binding is perfectly legal for any programs using them through Python. - It'd be great if we actually provided bsddb1, bsddb2, bsddb3 (and bsddb4?) modules which compile against the older libraries so databases written with any version could be accessed in Python. Maybe that's not exactly the right way to do it, but I don't think Python should be limited to just one version of Berkeley db. I've no idea what the default ought to be -- there's no clear winner. MvL> It would come as a bsddb3 package, which acts MvL> interface-compatible with the current bsddb module. Various MvL> submodules give access to more advanced features. I often "import bsddb3 as bsddb". MvL> The main rationale for dropping bsddb is that it still relies MvL> on the db_185.h interface, which will be phased out sooner or MvL> later. Existance of this interface, in turn, results in MvL> problems with anydbm: As mentioned above, I can see reasons for wanting to access any version of Berkeley db. -Barry

Sounds like a good plan, but we should make sure it can all be re-released under the PSF license. For the Zope Corp. portions of the code I promise that's no problem :-) -- but there are so many other contributors that it's getting a little tangled...

Ok, I'll investigate. Martin

>> - It'd be great if we actually provided bsddb1, bsddb2, bsddb3 (and >> bsddb4?) modules which compile against the older libraries so >> databases written with any version could be accessed in Python. Martin> I'm not sure how that would work, though. Agreed. I think trying to use multiple versions of libdb-generated files simultaneously is a disaster waiting to happen. It's unfortunate that the folks at Sleepycat haven't been able to provide a more consistent data format, but I understand that stuff is internal details and can change. They have been pretty good about providing update tools. What would be useful is if whatever bsddb module is installed could be more intelligent about file version errors. Instead of reporting something inscrutable like >>> db = bsddb.hashopen("tour.db") Traceback (most recent call last): File "<stdin>", line 1, in ? bsddb.error: (-30990, 'Unknown error 4294936306') I'd like it to realize that it was asked to open an old format file and give a useful error message like: bsddb.error: (-30990, 'Attempt to open old format file - see db_upgrade(1)') Sleepycat's tools can do this in the face of old files: % file tour.db tour.db: Berkeley DB (Hash, version 5, native byte-order) % db_dump tour.db > tour.txt db_dump: tour.db: hash version 5 requires a version upgrade db_dump: open: tour.db: DB_OLDVERSION: Database requires a version upgrade % db_upgrade tour.db % file tour.db tour.db: Berkeley DB (Hash, version 7, native byte-order) % db_dump tour.db > tour.txt Martin> Also, I think it is rare that multiple versions are installed on Martin> a single system: I doubt BSDDB even supports simultaneous Martin> installation of multiple header file sets, on Unix. Actually, RedHat & Mandrake do. This leads to as many problems as it solves. Take a look at the code in setup.py: dblib = [] if self.compiler.find_library_file(lib_dirs, 'db-3.2'): dblib = ['db-3.2'] elif self.compiler.find_library_file(lib_dirs, 'db-3.1'): dblib = ['db-3.1'] elif self.compiler.find_library_file(lib_dirs, 'db3'): dblib = ['db3'] elif self.compiler.find_library_file(lib_dirs, 'db2'): dblib = ['db2'] elif self.compiler.find_library_file(lib_dirs, 'db1'): dblib = ['db1'] elif self.compiler.find_library_file(lib_dirs, 'db'): dblib = ['db'] db185_incs = find_file('db_185.h', inc_dirs, ['/usr/include/db3', '/usr/include/db2']) db_inc = find_file('db.h', inc_dirs, ['/usr/include/db1']) And it's still not correct, as Barry indicated yesterday. For example, suppose that even though db3 is installed on your system you want to only manipulate db2 databases (perhaps for compatibility with another machine). You're stuck and have to edit setup.py or use Modules/Setup to build bsddb. Martin> So even while you can have multiple versions of the shared Martin> library installed, compiling it for use with these libraries may Martin> be tricky. Got that right... ;-) Martin> For any other scenario, users are to blame for forgetting to Martin> update their database files when updating the libraries. In the presence of anydbm, it's not obvious that users should know what file format their underlying databases are. Skip

On Mon, Jan 07, 2002 at 11:10:00PM -0500, Barry A. Warsaw wrote:

...

...

...

...

...

"GvR" == Guido van Rossum writes:

GvR> Sounds like a good plan, but we should make sure it can all GvR> be re-released under the PSF license. For the Zope GvR> Corp. portions of the code I promise that's no problem :-) -- GvR> but there are so many other contributors that it's getting a GvR> little tangled...

I /think/ we're just talking mostly about Robin Dunn and Andrew Kuchling. From the description on the page, I can't quite tell whether any of Gregory P. Smith's original code remains.

i'm-sure-andrew-won't-mind-either-ly y'rs, -Barry

Consider any of my pybsddb/bsddb3 code that remains [some does i'm sure] placed under whatever open source license is needed, (PSF license, etc). (I prefer the code to be used, not bickered about :). -g -- Gregory P. Smith