python-ipfix
python-ipfix copied to clipboard
britram
Python 2.7 backport
I started some work on this (working with @janies), but the lack of test coverage and my unfamiliarity with ipfix makes me worry I'll break something.
Name Stmts Miss Cover Missing
----------------------------------------------
ipfix/__init__ 9 0 100%
ipfix/ie 112 15 87% 100, 115, 163, 166, 169, 172, 184, 187, 233, 245, 269, 287-288, 291, 321
ipfix/ieutils 36 28 22% 29-52, 56-63, 67-70
ipfix/message 218 53 76% 194, 255, 266-269, 288, 305-334, 352, 359, 363, 408, 411, 420-422, 500, 518, 530-533, 556, 589, 613, 619, 652-655, 678, 684-689, 715-717, 721-722
ipfix/reader 25 18 28% 42-44, 54-60, 71-77, 87
ipfix/template 188 32 83% 35-36, 89, 102, 114, 196-197, 213, 258, 282-286, 302, 307-312, 315-324, 337-341, 379
ipfix/types 126 23 82% 202, 205, 225-235, 271-274, 277-280, 349, 363-364, 371-372, 378-381
ipfix/v9pdu 138 107 22% 52-70, 73, 77-78, 81-90, 118-154, 165, 177-178, 181-185, 198-207, 215-217, 232-265, 275, 280, 283-298, 301-317
ipfix/writer 36 25 31% 40-43, 46-50, 63-65, 75, 87-88, 101-103, 107-109, 122-126, 138
----------------------------------------------
TOTAL 888 301 66%
Do you have any scripts or data you use for testing other than the doctests?
The only testing at this point is the doctest stuff, and a few scripts which use this (mainly for reading) in qof/pytools. Better coverage would be nice (should open a separate issue for it); lack of it is one of the reasons the release number is 0.9.x.
On the other hand, since nobody's using this on 2.7 anyway, I wouldn't worry about breaking anything in a 2.7 branch. :)
The main issues with porting back will be modules that aren't there (ipaddress being the one I know of off the top of my head) and handling iterator constructs that don't exist in 2.7 (biggest example is yield from, though you can do the same thing more awkwardly without it).
For exercising reading better than the test coverage provides, ensuring ipfix2csv provides identical results for a reasonably complex input (i.e. YAF output) on both branches is a pretty good start.
Andy Freeland wrote:
I started some work on this (working with @janies https://github.com/janies), but the lack of test coverage and my unfamiliarity with ipfix makes me worry I'll break something.
Name Stmts Miss Cover Missing ipfix/init 9 0 100% ipfix/ie 112 15 87% 100, 115, 163, 166, 169, 172, 184, 187, 233, 245, 269, 287-288, 291, 321 ipfix/ieutils 36 28 22% 29-52, 56-63, 67-70 ipfix/message 218 53 76% 194, 255, 266-269, 288, 305-334, 352, 359, 363, 408, 411, 420-422, 500, 518, 530-533, 556, 589, 613, 619, 652-655, 678, 684-689, 715-717, 721-722 ipfix/reader 25 18 28% 42-44, 54-60, 71-77, 87 ipfix/template 188 32 83% 35-36, 89, 102, 114, 196-197, 213, 258, 282-286, 302, 307-312, 315-324, 337-341, 379 ipfix/types 126 23 82% 202, 205, 225-235, 271-274, 277-280, 349, 363-364, 371-372, 378-381 ipfix/v9pdu 138 107 22% 52-70, 73, 77-78, 81-90, 118-154, 165, 177-178, 181-185, 198-207, 215-217, 232-265, 275, 280, 283-298, 301-317
ipfix/writer 36 25 31% 40-43, 46-50, 63-65, 75, 87-88, 101-103, 107-109, 122-126, 138
TOTAL 888 301 66% |
Do you have any scripts or data you use for testing other than the doctests?
— Reply to this email directly or view it on GitHub https://github.com/britram/python-ipfix/issues/2#issuecomment-27117327.
The main issues with porting back will be modules that aren't there (ipaddress being the one I know of off the top of my head) and handling iterator constructs that don't exist in 2.7 (biggest example is yield from, though you can do the same thing more awkwardly without it).
Yeah, I found backports or alternatives for most of the 3.3+ features, but yield from will become more awkward.
Is this backport still likely to happen, or is it abandoned? The fork appears about a year (and a hundred-plus commits) out of date.
So the intention is still to do this, but it'll clearly have to start over with a new branch. Unfortunately the 2.7 backport is pretty far down my prio list at the moment, so I wouldn't expect to be able to devote any effort before 2015.
On Fri, Sep 26, 2014 at 2:40 PM, Brett Higgins [email protected] wrote:
Is this backport still likely to happen, or is it abandoned? The fork appears about a year (and a hundred-plus commits) out of date.
— Reply to this email directly or view it on GitHub https://github.com/britram/python-ipfix/issues/2#issuecomment-56955933.
Any wild/ballpark estimate on the amount of effort required? I might be interested in contributing, especially if the test coverage has improved in the past year.
in develop-merge-27, need to verify a couple of things with the tests, will revisit this roll a 0.9.8 next week.
thanks and apologies for the short delay in merging... :)
Python 2.7.14 ipfix 0.9.7
Steps to reproduce:
pip install functools32
pip install py2-ipaddress
pip install pytz
pip install ipfix
- Attempt to import ipfix produces and import error:
[root@91888e677db3 tests]# python
Python 2.7.14 (default, Sep 28 2017, 16:40:48)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipfix
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/site-packages/ipfix/__init__.py", line 54, in <module>
from . import types
File "/usr/local/lib/python2.7/site-packages/ipfix/types.py", line 148, in <module>
from datetime import datetime, timedelta, timezone
ImportError: cannot import name timezone
Note: Python 2.7 datetime library does not include a timezone module
[root@91888e677db3 tests]# python
Python 2.7.14 (default, Sep 28 2017, 16:40:48)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dateime import timezone
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named dateime
