Re: svn commit: r1935586 - in subversion/branches/xml-schema-validation-improvements: . build subversion/tests/cmdline subversion/tests/cmdline/svntest

On 24. 6. 2026 16:03, Ivan Zhakov wrote:
> On Tue, 23 Jun 2026 at 17:42, Daniel Sahlberg 
> <[email protected]> wrote:
>
>     Den tis 23 juni 2026 kl 15:34 skrev <[email protected]>:
>
>         Author: ivan
>         Date: Tue Jun 23 13:33:58 2026
>         New Revision: 1935586
>
>         Log:
>         On 'xml-schema-validation-improvements' branch:
>
>         Always use installed lxml and rnc2rng Python packages to
>         validate XML output
>         of `svn --xml` in tests.
>
>         This change also makes these package mandatory for running
>         tests unless new
>         option `--disable-xml-schema-validation` is specified.
>
>
>     [...]
>
>     I had a few minutes to spare this afternoon so I checked this
>     commit and did three tests on Ubuntu 26.04:
>     - With python3-lxml install: make check succceeded
>     - Without python3-lxml installed: make check failed  with error
>     messages, this in the summary:
>     [[[
>     There were some XML validation errors,
>     checking/home/dsg/svn_branches/xml-schema-validation-improvements/tests.log
>     XML: Module lxml.etree not found
>     ]]]
>     - Without python3-lxml:  DISABLE_XML_SCHEMA_VALIDATION=true make
>     check succeed.
>
>     I think this looks good - fails by default but can be made to work.
>
>     I also tried cmake/ctest but that failed spectacularly with (62
>     tests failed) or without lxml (61 tests failed!), so I presume
>     something else is wrong.
>
>     Only thing remaining is to document this. "make check" is only
>     mentioned under "Building from a Tarball". Maybe it deserves a
>     separate section ("D. Running the test suite"). Possibly even
>     restructuring "II. Installation" to separate our three build
>     systems (autoconf/make, vcproj and CMake) and having a separate
>     section on testing under each? Do we do this on the branch or
>     after merging back to trunk?
>
>
> Thanks for testing this!
>
> There are a few things that still need to be done:
>
> 1. I learned that we can actually use the builtin Python XML package 
> to check the structural validity of XML responses. While this isn't 
> the same as fully validating the response against a schema definition, 
> it still lets us catch many cases where we produce invalid XML.
>
> In r1935590 I implemented this improvement and I'm now thinking about 
> making this mode the default, enabling full schema validation only if 
> explicitly requested. This way maintainers that run tests in their 
> pipelines can still get an adequate level of checking without being 
> required to install additional packages. And we ourselves will enable 
> the full validation in GitHub Actions.


I like this approach, with one small nit – there's no need to explicitly 
request schema validation, just check at runtime if the required modules 
(lxml and rng2rnc) are available and if they are, perform full 
validation. There is/was already code in svntest/main.py to check that.


> This new validation produces less verbose, but still useful error 
> messages, for example:
>
> Full schema check:
> [[[
> There were some XML validation errors, 
> checking/root/svn-trunk/out1/tests.log
> XML: Opening and ending tag mismatch: log line 2 and logentry, line 3, 
> column 12 (<string>, line 3)
> XML: Opening and ending tag mismatch: log line 2 and logentry, line 
> 37, column 12 (<string>, line 37)
> XML: PCDATA invalid Char value 8, line 10, column 12 (<string>, line 10)
> ]]]
>
> New simple XML structural validity check (added in r1935590):
> [[[
> There were some XML validation errors, 
> checking/root/svn-trunk/out1/tests.log
> XML: mismatched tag: line 3, column 2
> XML: mismatched tag: line 37, column 2
> XML: not well-formed (invalid token): line 10, column 11
> ]]]


Good enough for default and infinitely better than nothing.

OK, strictly speaking it's undefinedly better than nothing, unless we 
write lim(x -> 0) N/x instead of X/0.


> 2. On Mac OS, there is an issue where FindPython3() in CMake locates a 
> different Python binary that doesn't match `python` from the command 
> line [1].
>
> I still need to sort this part out.


It probably finds /usr/bin/python3 by default, which is Python 3.9 on 
recent versions of macOS. I think you'll have to set the 
Python3_ROOT_DIR hint. Given the python binary you get on the command 
line, try this:

python3 -c 'import pathlib, sys; print(str(pathlib.Path(sys.executable).resolve().parent.parent))'



This strips the executable name and the bin/ directory component from 
the absolute path. For me, the output was:

/opt/homebrew/Cellar/[email protected]/3.14.6/Frameworks/Python.framework/Versions/3.14


which is correct.

-- Brane