On 3. 6. 2026 20:48, Daniel Sahlberg wrote:
Den ons 3 juni 2026 kl 03:09 skrev Branko Čibej <[email protected]>:
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.
I agree that we should test it but I also feel a bit uncomfortable
seeing the test suite download something from the internet.
I don't see a problem if the test suite fail by default if lxml (or
other dependencies) isn't installed beforehand. I think it would be
perfectly fine to require someone running the test suite to actually
install dependencies on their system. Of course we should then
document the required modules in INSTALL, I'm happy to help doing that.
On many systems there is no easy way to install those dependencies.
Windows is a known problem, but so is macOS. Why on earth should we put
an extra burden on developers when the solution is already implemented
and works? This is exactly what any Python project does for local
development and testing. And before anyone draws parallels to NPM, well,
there aren't that many.
Now frankly, I'm not interested in discussing this any more. I've
explained my position and why I think what we're doing is just about as
safe as downloading a compiler from the internet – which anyone who
builds Subversion does on a regular basis anyway. Whoever wants to rip
this effort up and throw it away, be my guest. Of course it would make
more sense to put that effort into fixing invalid XML output, but I'm
not one to tell other people how to spend their time.
-- Brane
