Remark on Windows builds: python-build 3.12.11 of sqlite3.dll is sqlite-3.47.1, while official cpython-3.12.10 uses sqlite-3.49.1

[stonebig]

maybe it is an involontary deffect ?

checked on
https://github.com/astral-sh/python-build-standalone/releases/download/20250612/cpython-3.12.11+20250612-x86_64-pc-windows-msvc-install_only_stripped.tar.gz

https://github.com/astral-sh/python-build-standalone/releases/download/20250612/cpython-3.12.11+20250612-x86_64-pc-windows-msvc-install_only.tar.gz

cpython commit was of March 31st 2025:

python/cpython@45a3ab5

[zanieb]

We can just upgrade, thanks!

[stonebig]

Why does it seems not that simple ?

[zanieb]

Alas they changed their build system so we actually are encountering a hiccup at #667 (comment)

[geofft]

I'm also curious - while it's good to upgrade dependencies in general, is there something specific that's making you ask for matching versions with the official Windows releases? Should we add a test/automation/something to ensure that our version is at least as new as the official build?

[stonebig]

I'm also curious - while it's good to upgrade dependencies in general, is there something specific that's making you ask for matching versions with the official Windows releases? Should we add a test/automation/something to ensure that our version is at least as new as the official build?

I was suggested to use prepared uv builds of python rather than official python.org.
Except for the way it's compiled, like tail-call, I would consider differences somewhat a bug.

So, I compared and found:

• nice differences: python-3.12.11 compiled for windows, no \docs or news.txt
• no-reason differences: sqlite not same version.
• maybe some smaller differences after that, but waiting this one fixed to check more.

[zanieb]

Except for the way it's compiled, like tail-call, I would consider differences somewhat a bug.

Just to be clear, using different versions of dependencies is not going to be considered a bug here. For other platforms, e.g., Linux, there are no official builds and, for example, we may prioritize consistency in versions across our distributions rather than match the versions used on Python.org for Windows. We also may upgrade versions before Python.org does.

While I think it's reasonable to minimize the differences, we take correctness and bugs seriously so I think it's important to clarify this point.

[geofft]

@stonebig, can you please provide some more details on what you're looking for with the SQLite configuration and to what extent it needs to match the configuration from python.org?

I've just learned that we have a difference between the configuration of SQLite on Windows and on other platforms. On other platforms, the configuration of SQLite is managed in this repo because we run ./configure. On Windows, the configuration of SQLite is managed inside the CPython source. In practice, this means that there are some extensions that are present on Mac/Linux that are not present on Windows (in PCbuild/sqlite3.vcxproj). Also, on Linux/Mac, the same extensions are used on all Python versions, but on Windows, older versions don't have as many extensions enabled as newer versions.

It would be pretty easy to make the SQLite build consistent across platforms and enable these extensions on Windows, but I'm trying to decide if that's the right thing to do. In my opinion, consistency across platforms is good because you can write code on one platform and expect it to run on another. But if we make this change, our builds will diverge from the official python.org builds.

I would like to get your opinion. What is the correct behavior here and why?

Also, in your opinion, would it be okay if we had a newer SQLite version than the python.org builds use? Or would you consider that a bug, too?

[stonebig]

It's curious you say the official build was not align, as the worry was you were not doing it
Maybe I mistaken.