Conversation
jafingerhut
left a comment
There was a problem hiding this comment.
I hereby resolve to not mention again that backwards compatibility is very nice thing to preserve. :-)
Anyone that wants to keep using scapy can still do so by switching the module. We can also still add the warning and have one or two releases display it until we pull the trigger. Now with a consistent release cycle this really should not be a problem. |
27b19b5 to
cad1806
Compare
While I won't mention the above again, I will request that when this is merged, that we increase the major version number of this package, e.g. to version 1.0.0, which by my understanding of semantic versioning is the signal that there are backwards-incompatible breaking changes in that version. |
|
I have looked the CI test failures, an experimenting locally to see if I can find changes that enable them to pass. At the moment, all I think that I have learned is that the call stack of the failure includes the line However, then it still fails with this exception: because that is part of what method _calculate_fields_offset_and_bitwidth in file mask.py is trying to do. That code seems to rely upon attributes of class Ether that Scapy defines, but bf_pktpy does not. This is part of the "deep and wide" nature of Scapy that I pointed out earlier -- even ptf's implementation has parts in it that rely on Scapy, that not even the bf_pktpy implementers bothered to reimplement. We could disable that test, but if we do, we should probably disable the |
Resolve the issues that we provide the GPL scapy module with PTF.