On 2. 6. 2026 13:29, Ivan Zhakov wrote:
On Mon, 1 Jun 2026 at 23:01, Branko Čibej <[email protected]> wrote:
On 1. 6. 2026 22:30, Branko Čibej wrote:
On 1. 6. 2026 22:25, Branko Čibej wrote:
On 1. 6. 2026 17:41, Ivan Zhakov wrote:
On Fri, 22 May 2026 at 13:50, Branko Čibej <[email protected]>
wrote:
On 22. 5. 26 12:27, Branko Čibej wrote:
On 22. 5. 26 11:50, [email protected] wrote:
Author: brane
Date: Fri May 22 09:50:14 2026
New Revision: 1934497
Log:
Allow the tests to work with a non-standart Python 3 installation that
does not provide the 'venv' module.
This commit addresses some of Ivan's concerns.
1. The 'venv' module isn't available
'venv' is part of the Python standard library, so strictly
speaking, it should always be available to the tests. But
it's no big deal to make it conditional. If it's not
present, the test driver won't attempt to create a virtual
environment or download any dependencies.
I tested this with CMake, but the graceful degradation doesn't
seem to be working. In my case, configuration fails with an
AssertionError:
[[[
cmake -B out\1 -S .
"-DCMAKE_TOOLCHAIN_FILE=..\vcpkg\scripts\buildsystems\vcpkg.cmake"
"-DSVN_ENABLE_RA_SERF=OFF" "-DSVN_ENABLE_TESTS=ON"
"-DPython3_ROOT_DIR=..\python" "-DPython3_FIND_REGISTRY=NEVER"
-- Selecting Windows SDK version 10.0.26100.0 to target Windows
10.0.26200.
Traceback (most recent call last):
File "C:\Ivan\OpenSource\svn-trunk\build\run_tests.py", line
1167, in <module>
main()
File "C:\Ivan\OpenSource\svn-trunk\build\run_tests.py", line
1117, in main
main_create_venv(opts, args)
File "C:\Ivan\OpenSource\svn-trunk\build\run_tests.py", line
1161, in main_create_venv
python_prog, _ = svntest.main.create_python_venv(venv_dir,
quiet=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"C:\Ivan/OpenSource/svn-trunk\subversion\tests\cmdline\svntest\main.py",
line 2500, in create_python_venv
assert venv is not None
^^^^^^^^^^^^^^^^
AssertionError
CMake Error at CMakeLists.txt:892 (message):
run_tests.py --create-python-venv failed.
<...>
How come we're not seeing that in CI?
My experiment was performed in an offline environment, whereas the CI
has access to the Internet.
[...]
I'll point out once more that running tests without a full Python
3 installation is not officially supported. Python 3 without the
'venv' module is not Python 3. You really should update INSTALL
about that.
It's worth noting that this is an officially supported installation
method.
I can't find this documented either in HACKING or INSTALL. The latter
only mentions Python 3, not some subset.
And it is currently the only way to perform an unattended installation
of Python on Windows. For that reason, I firmly believe it is a
configuration we need to continue accounting for.
I never said we shouldn't support it, but I find this moving of
goalposts and calling the result "official" less than optimal. If you
want this to be officially supported, then please:
* document it
* help support it in code
Regarding the topic in general: enforcing XML validation in every
dev's environment is a nice goal, but I would say it isn't really
worth it if we risk introducing regressions to the build and testing
processes.
I think that if we make validation entirely optional and have a CI
instance checking the schema, that's already good enough. The feedback
loop will become a bit longer, but we still won't miss any issues in
the long run.
Given that we currently have 3 tests that produce invalid XML, and we
didn't even know about it until I added XML validation, I think we
should go the other way: make the XML output validation in tests
mandatory and default unless explicitly disabled during the test run.
Right now, we're breaking our own API contract.
"Let's not test because it's not convenient" is not an attitude that I
can support.
-- Brane
