On 6/22/20, Steve Dower wrote:
>
> What is likely happening here is that _sqlite3.pyd is being imported
> before _mapscript, and so there is already a SQLITE3 module in memory.
> Like Python, Windows will not attempt to import a second module with the
> same name, but will return the original
It's still a problem, even if it's a problem in the opposite direction than
you first thought (Python has a newer sqlite, rather than older). Updating
your API fixes the problem now, but you still need to decide how you check
for and handle newer, potentially incompatible library versions.
On
Thanks Ned.
I did double check the docs for sqlite3 after posting and wondering why the
versions were so different.
I guess the clue should have been the sqlite-3 !
Reading the history of the module I presume sqlite3 has its own module version
number as it was integrated from a separate
Thanks Steve for the clarifications.
As a workaround placing the older sqlite3.dll in the same folder as the
_mapscript.pyd file while leaving all the other DLLs in a different folder
referenced by add_dll_directory allows for a successful import.
For a less hacky fix - after checking the
On Jun 22, 2020, at 05:39, Seth G wrote:
> However, there is one feature of using the Windows PATH that I can't seem to
> replicate with add_dll_directory.
> The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2
> is linked to 2.6.0. Building with matching versions is not
On 22Jun2020 1646, Steve Dower wrote:
DLLs should not be in the search path at all - it's searched by sys.path
when importing .pyd files, which are loaded by absolute path and their
dependencies found adjacent.
To clarify this - by "DLLs" I meant the DLLs directory, not DLLs in
general
On 22Jun2020 1039, Seth G wrote:
However, there is one feature of using the Windows PATH that I can't seem to
replicate with add_dll_directory.
The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2 is
linked to 2.6.0. Building with matching versions is not something I can
