Python packages
I just wanted to add some network related python packages (dpkt and netifaces) to buildroot. At the moment we have only pyserial as external python component, residing in packages/python-serial. Should I pack these packages just under Libraries->Networking or should I create special folder packages/python-addons and put those packages there?
Best regards,
Yegor
Hello,
Le Wed, 14 Dec 2011 08:41:41 +0100,
Yegor Yefremov <[email protected]> a ?crit :
Quoted 3 lines
I just wanted to add some network related python packages (dpkt and netifaces) to buildroot. At the moment we have only pyserial as external python component,
And python-mad, in package/multimedia/
Quoted 3 lines
residing in packages/python-serial. Should I pack these packages just under
Libraries->Networkingor should I create special folder packages/python-addons and put those packages there?
Your question is strange because you're comparing a location in menuconfig ("Libraries->Networking") and a location in the source tree ("packages/python-addons") while the two are not related.
From a source tree location perspective, Peter's wish is to keep everything directly under package/ as much as possible. So we would have there python/, python-serial/, python-something/, python-somethingelse/ and so forth. But I think they should all start with the python- prefix. This wasn't done with Lua extensions and I am personally not happy with this.
Now, for the location in menuconfig, I must say I don't know. Should we sort them by Language (Python extensions, Lua extensions) or by usage type (Network, Multimedia, etc.). So far, the extensions are listed "by usage", along with all other libraries for the same type of usage.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Am 14.12.2011 08:46, schrieb Thomas Petazzoni:
Quoted 8 lines
Hello,
Le Wed, 14 Dec 2011 08:41:41 +0100,
Yegor Yefremov <[email protected]> a ?crit :Quoted 3 lines
I just wanted to add some network related python packages (dpkt and netifaces) to buildroot. At the moment we have only pyserial as external python component,
Quoted 8 lines
And python-mad, in package/multimedia/
Quoted 3 lines
residing in packages/python-serial. Should I pack these packages just under
Libraries->Networkingor should I create special folder packages/python-addons and put those packages there?Your question is strange because you're comparing a location in menuconfig ("
Libraries->Networking") and a location in the source tree ("packages/python-addons") while the two are not related.
I know I just wanted to cover both topics at a time: location in packages and in configuration.
Quoted 6 lines
From a source tree location perspective, Peter's wish is to keep everything directly under package/ as much as possible. So we would have there python/, python-serial/, python-something/, python-somethingelse/ and so forth. But I think they should all start with the python- prefix. This wasn't done with Lua extensions and I am personally not happy with this.
O.K. Than I'll add python- prefix.
Quoted 4 lines
Now, for the location in menuconfig, I must say I don't know. Should we sort them by Language (Python extensions, Lua extensions) or by usage type (Network, Multimedia, etc.). So far, the extensions are listed "by usage", along with all other libraries for the same type of usage.
That's a good question. I see here 3 possibilities:
1. by usage
2. by language
3. both by usage and language
The latter makes more work but would be easier for users to find. IMHO
For Python we have "core components" section so we could add "external components" one and place usage hierarchy there or at first without usage hierarchy, till the number of packages will exceed the manageable count.
Yegor
Hi,
Quoted 26 lines · Thomas Petazzoni
Hello,
Le Wed, 14 Dec 2011 08:41:41 +0100,
Yegor Yefremov <[email protected]> a ?crit :Quoted 3 lines
I just wanted to add some network related python packages (dpkt and netifaces) to buildroot. At the moment we have only pyserial as external python component,
And python-mad, in package/multimedia/
Quoted 3 lines
residing in packages/python-serial. Should I pack these packages just under
Libraries->Networkingor should I create special folder packages/python-addons and put those packages there?Your question is strange because you're comparing a location in menuconfig ("
Libraries->Networking") and a location in the source tree ("packages/python-addons") while the two are not related.From a source tree location perspective, Peter's wish is to keep everything directly under package/ as much as possible. So we would have there python/, python-serial/, python-something/, python-somethingelse/ and so forth. But I think they should all start with the python- prefix. This wasn't done with Lua extensions and I am personally not happy with this.
Quoted 4 lines
Now, for the location in menuconfig, I must say I don't know. Should we sort them by Language (Python extensions, Lua extensions) or by usage type (Network, Multimedia, etc.). So far, the extensions are listed "by usage", along with all other libraries for the same type of usage.
I think this should depend on what you consider a 'python package'. Is a script written in Python a python package? In my opinion it is not. With this reasoning, such a script should be under package/scriptname and be listed in the relevant menuconfig category. For example, 'dstat' is a system monitoring tool written in Python, and I think it belongs under "Debugging, profiling and benchmark".
However, packages that really are extensions, i.e. add functionality to the language that can be used by scripts written in that language, e.g. serial communication capabilities, could be added in package/python-foo as you suggest, and I would put them under a language-specific menu in menuconfig. Things like python-mad, dpkt and netifaces would fit under this category.
My reasoning is that if you as a developer need such a package, then you already know that you need a Python interface, and so the step to going to the Python menu. But, for scripts like dstat, you typically don't care whether it's written in Python or another language and thus you don't expect it to be present in the python menu but rather in the related category.
Best regards,
Thomas
Le Wed, 14 Dec 2011 09:01:56 +0100,
Thomas De Schampheleire <[email protected]> a ?crit :
Quoted 6 lines
I think this should depend on what you consider a 'python package'. Is a script written in Python a python package? In my opinion it is not. With this reasoning, such a script should be under package/scriptname and be listed in the relevant menuconfig category. For example, 'dstat' is a system monitoring tool written in Python, and I think it belongs under "Debugging, profiling and benchmark".
Agreed.
Quoted 6 lines
However, packages that really are extensions, i.e. add functionality to the language that can be used by scripts written in that language, e.g. serial communication capabilities, could be added in package/python-foo as you suggest, and I would put them under a language-specific menu in menuconfig. Things like python-mad, dpkt and netifaces would fit under this category.
Right.
Quoted 6 lines
My reasoning is that if you as a developer need such a package, then you already know that you need a Python interface, and so the step to going to the Python menu. But, for scripts like dstat, you typically don't care whether it's written in Python or another language and thus you don't expect it to be present in the python menu but rather in the related category.
Agreed.
For Lua, it's done this way, i.e all Lua extension packages are grouped in a sub-menu of the Lua interpreter.
For Python, the python-mad and python-serial packages have been put in their respective topics (Multimedia and Hardware handling I guess). Would probably be good to move them in a sub-menu of the Python interpreter.
Regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com