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. Kind regards, Daniel
