Issue #910, #48, #102 - Require Python 3.9 in RPM package

[jiridanek]

As the linked issue explains, Python 3.6 is out-of-upstream-support. Is it possible to use a newer Python on ubi8? Yes! Is it advisable? Not sure. Can it be done for RPMs too? Yes! It would be easy if there was python-proton packaged for python39. But there is not one.

The solution needed for the RPM is a real mess (and it is only a good fortune that it plugs into an already existing mess with skupper-router-internal and sys.path modifications that the router already implements).

I think that if Python >3.6 was deemed worth the effort, it would be necessary to either have a python39-qpid-proton RPM package (which does not have file conflicts with the python3-qpid-proton package) or decide only package the skrouterd in a RPM and distribute the sktools using pip, or something along these lines.

I am not myself convinced this Python 3.9 is a good idea, overall. It is interesting, though, that CentOS/ubi has support for using non-system version of Python for RPMs. On CentOS, there is even automatic rewrite of the #! in scripts to use Python 3.9 (or whichever version is chosen).

• See the The unbearable optionality of dependencies and features #48 issue for detailed discussion.

[codecov-commenter]

Codecov Report

Merging #398 (1a7947a) into main (b9ffb33) will decrease coverage by 0.08%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #398      +/-   ##
==========================================
- Coverage   78.00%   77.93%   -0.08%     
==========================================
  Files         239      239              
  Lines       60753    60754       +1     
  Branches     5585     5585              
==========================================
- Hits        47392    47348      -44     
- Misses      10748    10781      +33     
- Partials     2613     2625      +12     

Flag	Coverage Δ
pysystemtests	87.42% <ø> (-0.09%)	⬇️
pyunittests	54.44% <ø> (ø)
systemtests	71.61% <ø> (-0.07%)	⬇️
unittests	27.19% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
calculator	30.78% <ø> (+<0.01%)	⬆️
systemtests	78.51% <ø> (-0.08%)	⬇️

[jiridanek]

The idea is that as we need to build skupper RPMs, we cannot depend on python39-qpid-proton (because, I am assuming, it is not yet available). Therefore, it is necessary to build the python binding for proton here, and ship it (in rpm skupper-router-common). That is the cause for most of the changes in the PR diff

Next, replacing python3 with python39 constitutes the rest of the diff.

[jiridanek]

I tried building this on COPR, which showed the following repeated test fail

======================================================================
FAIL: test_80_stats (system_tests_tcp_adaptor.TcpAdaptor)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/skupper-router/tests/system_tests_tcp_adaptor.py", line 1337, in test_80_stats
    self.assertEqual(es_inta_connections_opened, 7)
AssertionError: 6 != 7

e.g. https://download.copr.fedorainfracloud.org/results/jdanek/skupper-router/epel-8-aarch64/05281012-skupper-router/builder-live.log.gz

I am wanting to dismiss this as just some timing issue on lowpowered build machine, but it happens everywhere!

The build results are at https://copr.fedorainfracloud.org/coprs/jdanek/skupper-router/build/5281012/, the failed states mean failed tests, not failed compilation

[jiridanek]

yeah, this is now out of date, proton python is using cffi; but early this week it still worked with main

[jiridanek]

• Should I close this as rejected, based on discussion in Set proton version in CI to 0.39.0 #1115 (comment)?

[ganeshmurthy]

• Should I close this as rejected, based on discussion in Set proton version in CI to 0.39.0 #1115 (comment)?

Yes please, thanks.

[ganeshmurthy]

@jiridanek Can this PR can be closed in favor of #1120 ?

[jiridanek]

@jiridanek Can this PR can be closed in favor of #1120 ?

I like the idea of building python-qpid-proton as part of this RPM build, so that we would no longer mix embedded proton with nonembedded proton. That's something I think can still be used.

What was the long-term plan about embedding proton, anyways? I think that it will be done for the foreseeable future, yes? It is not something we want to abandon. In that case, I'd completely remove dependency on python3-qpid-proton and build the proton python here, and embed it for private use by skstat and skmanage.

Wdyt?, thanks