On 09/25/2017 05:02 AM, Marco Varlese wrote:
Thanks for the thorough explanation Klement!Based on that, I think (2) is still
the better option for the current situation...
Tom, how would that sound to you?
"Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" <ksek...@cisco.com>
09/25/17 10:40 AM >>>
Quoting Marco Varlese (2017-09-25 10:26:50)
Hi Klement,
"Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" <ksek...@cisco.com>
09/25/17 9:33 AM >>>
At the time of creating this patch, epel was part of Makefile and
python34 was installed as dependency from that repo.
(see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
At later time, the epel stuff disappeared and with it also
the possibility to add python34 as a centos dependency - commit
bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
in discussion with Neale, but I didn't get a chance to test whether
centos works or not before it was merged.
That's OK. You would have had to test with a system without EPEL Repo
enabled to discover this problem.
I should have paid closer attention when this patch was first discussed
in May. Please add me as a reviewer for patches that have implications
for RPM packaging and requirements.
I think it would be nice though to update other scripts too so to have one
single python version used across the board.
Currently, to build VPP on our distribution I need to require both python and
python3 packages since some python scripts use one rather than the other.
Aligning python versions would make downstream consumption better I believe.
Is this something which will/could be done?
See below.
As for the solution, I can think of 3 options:
1.) require python3 (which has been around for some ~9 years now)
2.) disable generation of the C (and C++) API if python3 is not detected
I think this would be a fair compromise for distros not supporting (yet)
python3. However, I am not sure how this would result in the VPP CI... wouldn't
this break all tests running over those API?
Tests are python2.7 because scapy wasn't python3 capable when we
designed the test framework.
These are language bindings, not different API calls. Only test_vapi,
which tests that the language bindings of different types (simple
request, dump, event, etc.) work would have to be disabled.
I think this is a good interim work-around until the distros have
Python3. I can submit another patch to allow this the inclusion would be
enabled as a default but could be disabled only in downstream builds in
RHEL and Centos 7.
When will we have tests in CSIT that use the C/C++ APIs in 17.10?
Neale, are we planning to cherry-pick this patch into 17.10?
Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?
3.) convert the script to python2.7 (which is in the opposite direction of
where we would want to go wrt python version)
Thanks,
Klement
Cheers,
Marco
Quoting Thomas F Herbert (2017-09-23 15:55:10)
All:
Commit 8f2a4ea, Gerrit, [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
API"
introduces a dependency on Python 3 and breaks downstream builds for
Centos.
Unfortunately, neither RHEL nor Centos currently support Python 3.
Most VPPers are probably building with EPEL repo so this problem didn't
show up until now but actually there is no dependency on EPEL in the
Makefile or spec file.
If anybody can suggest a solution short of pushing Python 3 into the
downstream repos, I am open to suggestions.
--Tom
--
Thomas F Herbert
NFV and Fast Data Planes
Office of Technology
Red Hat
References
Visible links
1. https://gerrit.fd.io/r/#/c/6983/
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
