>>>>> "GPS" == Gregory P Smith <greg@electricrain.com> writes:
GPS> This sounds good. Here's what i see on the plate to be done
GPS> so far:
GPS> 1) move the existing Modules/bsddbmodule.c to a new
GPS> Modules-old or directory.
mkdir Modules/old (or Modules/extensions-old)
mv Modules/bsddbmodule.c Modules/old
GPS> 2) create a new Lib/bsddb
GPS> directory containing bsddb3/bsddb3/*.py from the pybsddb
GPS> project.
+1
GPS> 3) create a new Modules/bsddb directory containing
GPS> bsddb3/src/* from the pybsddb project (the files should
GPS> probably be renamed to _bsddbmodule.c and
GPS> bsddbmoduleversion.h for consistent naming)
I don't think you need to create a new directory under Modules for
this; it's just two files. Probably Modules/_bsddbmodule.c and
Modules/_bsddbversion.h are fine.
Also, for backwards compatibility, won't Lib/bsddb/__init__.py need to
do "from _bsddb import btopen, error, hashopen, rnopen"?
GPS> 4) place the pybsddb setup.py in the Modules/bsddb directory,
GPS> modifying it as needed. OR modify the top level setup.py
GPS> to understand how to build the pybsddb module. (there is
GPS> code in pybsddb's setup.py to locate the berkeleydb install
GPS> and determine appropriate flags that should be cleaned up and
GPS> carried on)
How much of Skip's recent changes to setup.py can be retargeted for
pybsddb?
GPS> 5) modify the top level python setup.py to build the bsddb
GPS> module as appropriate. 6) "everything else" including
GPS> integrating documentation and pybsddb's large test suite.
What to do about the test suite is a good question. pybsddb's is
/much/ more extensive, and I wouldn't want to lose that, but I'm also
not sure I'd want it to run during a normal regrtest.
Here's an idea: leave test_bsddb as is and add pybsddb's as
test_all_bsddb.py. Then add a "-u all_bsddb" to regrtest's resource
flags.
GPS> How do we want future bsddb module development to proceed? I
GPS> envision it either taking place 100% under the python
GPS> project, or taking place as it is now in the pybsddb project
GPS> with patches being fed to the python project as desired? Any
GPS> preferences? [i prefer to not maintain the code in two
GPS> places myself (ie: do it all under the python project)]
I'd like to see one more official release from the pybsddb project,
since its cvs has some very useful additions (important bug fixes plus
support for BerkeleyDB 4). Then move all development over to the
Python project and let interested volunteers port critical patches
back to the pybsddb project. If you add me as a developer on
pybsddb.sf.net, I'll volunteer to help.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4