>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:
SM> If you want to lock bsddb down to the 1.85 API, force it to
SM> only build with db2 or db3 and reject attempts to compile/link
SM> it with db1.
That's more in line with what I was thinking.
BAW> pull pybsddb (which exports as module bsddb3) for Berkeley
BAW> 3.3.11. If there's a clamor for it, I suppose we could fake
BAW> a bsddb2 and bsddb4 for those major versions of Berkeley.
SM> Why the proliferation? I can see the argument for
SM> incorporating pybsddb into the core because it offers greater
SM> functionality, but why incorporate version names into module
SM> names that track releases? If Sleepycat's behavior in the
SM> past is any indication of its behavior in the future, they
SM> will change both the API and file formats in every release and
SM> give you various, incompatible tools with which to migrate
SM> each time.
The problem seems to be trying to figure out which API is available
and which you want to use. You might even want to use more than one
in any given Python installation. So it seems reasonable to be
explicit about the version of the API you need.
I'd still default "bsddb" to the 1.85 API even if that links with a
later version of the library/headers (as long as it's consistent, as
you suggested). Since pybsddb3 already exports itself as `bsddb3'
that seems to make sense too, although how that interacts with
Berkeley DB 4.0.14, I'm not sure (maybe that blows my theory).
-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