Shiboken is alright because it's not an actual python library, it's a binary that generates python bindings. eg: https://shiboken.readthedocs.org/en/latest/commandlineoptions.html J. Leclanche On Mon, Sep 2, 2013 at 12:29 AM, Xyne wrote:

On 2013-09-01 09:49 +0100 Jerome Leclanche wrote:

...

python-pyside would be the correct name for it. J. Leclanche

Yep. The same applies to "shiboken".

On 02/09/13 00:47, Jerome Leclanche wrote:

On Mon, Sep 2, 2013 at 12:29 AM, Xyne wrote:

...

On 2013-09-01 09:49 +0100 Jerome Leclanche wrote:

...

python-pyside would be the correct name for it. J. Leclanche

Yep. The same applies to "shiboken".

Shiboken is alright because it's not an actual python library, it's a binary that generates python bindings.

eg: https://shiboken.readthedocs.org/en/latest/commandlineoptions.html J. Leclanche

The shiboken package includes a python module (installed under site-packages) in addition to the commandline tool: https://shiboken.readthedocs.org/en/latest/shibokenmodule.html

On Mon, Sep 2, 2013 at 2:42 AM, kachelaqa wrote:

...

On 02/09/13 00:47, Jerome Leclanche wrote:

...

On Mon, Sep 2, 2013 at 12:29 AM, Xyne wrote:

...

On 2013-09-01 09:49 +0100 Jerome Leclanche wrote:

...

python-pyside would be the correct name for it. J. Leclanche

Yep. The same applies to "shiboken".

Shiboken is alright because it's not an actual python library, it's a binary that generates python bindings.

eg: https://shiboken.readthedocs.org/en/latest/commandlineoptions.html J. Leclanche

The shiboken package includes a python module (installed under site-packages) in addition to the commandline tool:

https://shiboken.readthedocs.org/en/latest/shibokenmodule.html

On 02/09/13 02:48, Jerome Leclanche wrote:

Ah. I suppose ideally they should be split...

Sounds reasonable. The equivalent sip tool for pyqt also has a python module which has been split out into separate packages (i.e. sip, python-sip and python2-sip).

It goes both ways; plenty of python- libs install binaries as well (eg. python-docutils installs a bunch of rst2* binaries). My python-bna https://aur.archlinux.org/packages/python-bna/ battle net authenticator library installs a command line authenticator as well. But packages like youtube-dl or namcap don't have provide an "official" api; they just happen to be python apps that import themselves. Then again, python-pip's main purpose is the "pip" binary. So in that way, I guess arch is inconsistent. And python-pip / youtube-dl operate the same way, by importing and loading themselves: [3:35:37] adys@azura ~ % cat /usr/bin/pip #!/usr/bin/python # EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.4.1','console_scripts','pip' __requires__ = 'pip==1.4.1' import sys from pkg_resources import load_entry_point if __name__ == '__main__': sys.exit( load_entry_point('pip==1.4.1', 'console_scripts', 'pip')() ) [3:36:44] adys@azura ~ % cat /usr/bin/youtube-dl #!/usr/bin/python import youtube_dl if __name__ == '__main__': youtube_dl.main() J. Leclanche On Mon, Sep 2, 2013 at 3:17 AM, Gabriel Ribeiro da Cruz Peixoto wrote:

I don't think spiting the application from it's library is a official policy, or at least it is not followed by all packagers. On my system I found many packages that don't have a python-* name and install files on site-packages:

$ pacman -Qo /usr/lib/python3.3/site-packages/ | cut -d ' ' -f 4 | grep -v '^python-' | xargs pacman -Sp --print-format "%r/%n" | sort community/nfoview community/reflector community/youtube-dl core/systemd extra/gedit extra/namcap extra/pyalpm extra/python extra/vde2 extra/xcb-proto

There are some obvious false positives on this list and I did not check every other one, but I know that namcap and youtube-dl provide a python module along with the main script.

[]'s Gabriel

On 02/09/13 05:43, kachelaqa wrote:

But the sip/shiboken packages aren't primarily python applications - they are development tools that generate python bindings for C/C++ libraries (such as Qt). The python modules they include can be built for use with either python2 or python3. But the commandline tool itself can generate bindings for *both* python versions - so only one of them is needed.

It seems my memory is playing tricks on me with regard to shiboken: it looks like separate python2/python3 versions of the commandline tool *are* needed (unlike sip).