On 8. 6. 25 16:45, Nathan Hartman wrote:
On Tue, May 20, 2025 at 8:32 AM <br...@apache.org> wrote:
Author: brane
Date: Tue May 20 12:32:49 2025
New Revision: 1925717
URL: http://svn.apache.org/viewvc?rev=1925717&view=rev
<http://svn.apache.org/viewvc?rev=1925717&view=rev>
Log:
Add support for verifying the svn command's XML output against the
Relax NG
schemas that are defined in ./subversion/svn/schema. We use
lxml.etree.
* subversion/tests/cmdline/svntest/main.py: Import venv.
(venv_bin, venv_dir, SVN_TESTS_REQUIRE, dependencies_ensured:
New globals.
(ensure_dependencies): Create a Python virtual environment in
the test
working directory, install the dependencies and update sys.path.
(run_tests): Call ensure_dependencies().
* subversion/tests/cmdline/svntest/verify.py:
Import os but not sys, io.BytesIO and typing.Iterable.
(SVNXMLSchemaValidationError): New exception type.
(validate_xml_schema): Validate the XML output of 'svn' against
a schema.
* subversion/tests/cmdline/svntest/actions.py
(run_and_verify_svn_xml, run_and_verify_svn_xml2): New functions
that
run XML validation.
* subversion/tests/cmdline/blame_tests.py,
subversion/tests/cmdline/log_tests.py: Add XML validation
* build/run_tests.py
(TestHarness._init_py_tests): Update PYTHONPATH to point at the
virtualenv.
This:
* Makefile.in (check): No, Python 2.7 is no longer required.
and...
Modified:
subversion/trunk/Makefile.in
subversion/trunk/build/run_tests.py
subversion/trunk/subversion/tests/cmdline/blame_tests.py
subversion/trunk/subversion/tests/cmdline/log_tests.py
subversion/trunk/subversion/tests/cmdline/svntest/actions.py
subversion/trunk/subversion/tests/cmdline/svntest/main.py
subversion/trunk/subversion/tests/cmdline/svntest/verify.py
Modified: subversion/trunk/Makefile.in
URL:
http://svn.apache.org/viewvc/subversion/trunk/Makefile.in?rev=1925717&r1=1925716&r2=1925717&view=diff
<http://svn.apache.org/viewvc/subversion/trunk/Makefile.in?rev=1925717&r1=1925716&r2=1925717&view=diff>
==============================================================================
--- subversion/trunk/Makefile.in (original)
+++ subversion/trunk/Makefile.in Tue May 20 12:32:49 2025
@@ -645,7 +645,7 @@ check: bin @TRANSFORM_LIBTOOL_SCRIPTS@ $
$$flags \
'$(abs_srcdir)' '$(abs_builddir)' $(TESTS);
\
else \
...this:
- echo "make check: Python 2.7 or greater is required,";
\
+ echo "make check: Python 3.6 or greater is required,";
\
echo " but was not detected during
configure"; \
exit 1; \
fi;
So I guess that as of 1.15, we'll actively drop support for Python 2.7.x?
That could be a good thing. After all, Python 2.7 has been deprecated
for more than 10 years and EOL since before 1.14.0. Removing support
for Python 2.7 could help clean up and simplify the Python parts of
our codebase.
However, the impression I got from past discussions was that we should
try not to break compatibility with 2.7 if practical.
Perhaps it's time to revisit that? Should we just drop support for
Python 2.7 everywhere? Are there systems in use out there that are
still stuck with Python 2.7? Are there enough of them to justify the
extra efforts needed to support them?
As far as I could tell, our test suite already didn't run with 2.7. I
picked 3.6 because that's the earliest version that isn't EOL yet.
If we want to support 2.7, someone has to put in the work to actually
test that -- because we're not testing this anywhere, and even if we
spend a couple days to revert to supporting 2.7, the code will bitrot
quickly if it's not used.
At the very least, we should a github workflow that installs
2.7.something (.18? .17?) through pyenv and run with that. Better yet
would be an ASF builder that's tied into github where "python2" is
available. Should ask infra about that.
-- Brane
