Hi, I couldn't reopen bug #112727, so I've filed a new bug. The net-analyzer/scapy-1.0.2 ebuild doesn't install scapy as a python module, meaning that to use it in other projects it must be manually installed separately into the site-packages directory. An ebuild could install scapy.py into the site-packages directory, and then install a wrapper script into /usr/bin to run it directly. Obviously the wrapper script would need to know where to look for scapy, but this shouldn't be too difficult. This would then allow people to make use of the scapy library/framework with the line "import scapy". I'd say leave it in net-analyzer rather than dev-python, because otherwise people may never see it...
Created attachment 74077 [details] A scapy.py wrapper for /usr/bin/scapy A simple wrapper script that can be dropped into /usr/bin/ to run scapy.
Created attachment 74078 [details, diff] installs scapy python module a patch for scapy-1.0.2.ebuild that will install scapy.py into the site-packages folder.
CCing kloeri because he's so nice and he will help me with evaluating this. I don't like the wrapper idea btw, I'd prefer to copy it twice rather than having something named /usr/bin/scapy that's actually a wrapper.
Fair enough. I suppose having the wrapper could do more harm than good in the long run, but it's pretty trivial. I'm personally pretty impartial to the wrapper, but I would like to see scapy.py installed as a module.
Created attachment 74964 [details, diff] Diff that installs python module + takes care of .py[co] files Copying the scapy file twice is the cleanest solution to me, so I fixed up Scotts ebuild with .py[co] generation on installation and cleanup on removal.
Thx kloeri! ;) Commited. Closing the bug. Re-open if necessary.
