Xpra to publicly expose its modules
Dear Ahmed, At the moment xpra installs its modules privately to /usr/lib/xpra/xpra. While this path appears to be incorrect due to unnecessary nesting we have a bigger problem with hiding xpra modules which should be exposed publicly because Xpra is both application and a library. Although Xpra is mainly an application its modules can be used by frontends like winswitch, packaged by yours truly. In particular winswitch have an ugly workaround [1] to find private Xpra modules. This is something upstream already complained to me about. There are some other concerns articulated by upstream. From our discussion: Me: python-apps packaging team is clearly advise to install private modules whenever possible probably to avoid python namespace collision. Upstream: Looks totally wrong to me, especially seeing that we have python compiled extensions in wimpiggy and xpra (linked against libpython) and that python3 code is quite different too. Using /usr/lib/xpra means that you cannot have xpra installed against more than one python version. whereas the default/standard /usr/lib*/pythonN.N/site-packages/xpra allows that. IMO, the most compelling argument for shipping xpra in the regular installation path used by all python applications (except on debian.) and not in /usr/lib is going to be that xpra has shared objects linked with libpython, and one may want multiple versions of python installed, each with xpra - this is not possible with a single xpra in /usr/lib.. After all, winswitch could (and should?) fallback to the less optimal parsing of the xpra --version command line when loading the python package directly fails. Considering the above I'm attaching the patch to install Xpra modules to default location i.e. to /usr/lib/python2.N/dist-packages/xpra. After well over one month since I applied for membership in Python Applications Packaging Team I still got no reply to my application so I can't apply this patch myself. Anyway because this change could be considered controversial I wouldn't commit it without your consent. Also I'm CCing to debian-python in order to double check with the team that we're not going against policy or best practice. Please advise. Thank you. Best regards, Dmitry. [1]: https://winswitch.org/trac/changeset/5055 From f2a0235c1aeb373026da900ed47bd6bd51320a1b Mon Sep 17 00:00:00 2001 From: Dmitry Smirnov only...@member.fsf.org Date: Tue, 18 Sep 2012 18:11:51 +1000 Subject: [PATCH] xpra to publicly expose its modules. Xpra is both application and a library. Exposing modules publicly will simplify interaction with frontends like winswitch and will allow to install for more than one python version. The latter may be of concern due to some bindings that may be sensitive to python version. --- debian/changelog|3 +++ debian/patches/private-pkg.diff | 44 --- debian/patches/series |1 - debian/xpra.install |2 +- 4 files changed, 4 insertions(+), 46 deletions(-) delete mode 100644 debian/patches/private-pkg.diff delete mode 100644 debian/patches/series diff --git a/debian/changelog b/debian/changelog index 3ec5f5c..03bc27d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,8 +3,11 @@ xpra (0.3.6+dfsg-2) UNRELEASED; urgency=low * NOT RELEASED YET * debian/README.Debian: Remove Known issues section, it is invalidated with 0.3.6 release. + [ Dmitry Smirnov ] + * Dropped private-pkg.diff in order to publicly expose xpra modules. + -- أحمد المحمودي (Ahmed El-Mahmoudy) aelmahmo...@sabily.org Sun, 19 Aug 2012 09:04:44 +0200 xpra (0.3.6+dfsg-1) unstable; urgency=low diff --git a/debian/patches/private-pkg.diff b/debian/patches/private-pkg.diff deleted file mode 100644 index 0d4aed7..000 --- a/debian/patches/private-pkg.diff +++ /dev/null @@ -1,44 +0,0 @@ -Description: Add /usr/lib/xpra to sys.path for xpra script and /usr/lib/parti - to sys.path for parti script. -Author: أحمد المحمودي (Ahmed El-Mahmoudy) aelmahmo...@sabily.org -Forwarded: not-needed a/scripts/parti -+++ b/scripts/parti -@@ -1,6 +1,7 @@ - #!/usr/bin/env python - - import sys -+sys.path.append(/usr/lib/parti) - import parti.scripts.main - - parti.scripts.main.main(sys.argv) a/scripts/parti-repl -+++ b/scripts/parti-repl -@@ -1,6 +1,7 @@ - #!/usr/bin/env python - - import sys -+sys.path.append(/usr/lib/parti) - import parti.scripts.repl - - parti.scripts.repl.main(sys.argv) a/scripts/xpra -+++ b/scripts/xpra -@@ -1,6 +1,7 @@ - #!/usr/bin/env python - - import sys -+sys.path.append(/usr/lib/xpra) - import xpra.scripts.main - - sys.exit(xpra.scripts.main.main(__file__, sys.argv)) a/scripts/xpra_launcher 2012-06-03 19:16:59.330360871 +0200 -+++ b/scripts/xpra_launcher 2012-06-03 19:20:40.515457660 +0200 -@@ -1,5
Re: Xpra to publicly expose its modules
Hello, On Tue, Sep 18, 2012 at 06:27:21PM +1000, Dmitry Smirnov wrote: Although Xpra is mainly an application its modules can be used by frontends like winswitch, packaged by yours truly. In particular winswitch have an ugly workaround [1] to find private Xpra modules. This is something upstream already complained to me about. ---end quoted text--- Ok, but in that case, should the package be renamed to python-xpra since the python modules will be public ? Or can the package still keep the name 'xpra' ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: Xpra to publicly expose its modules
On Wed, 19 Sep 2012 01:23:39 أحمد المحمودي wrote: Hello, On Tue, Sep 18, 2012 at 06:27:21PM +1000, Dmitry Smirnov wrote: Although Xpra is mainly an application its modules can be used by frontends like winswitch, packaged by yours truly. In particular winswitch have an ugly workaround [1] to find private Xpra modules. This is something upstream already complained to me about. ---end quoted text--- Ok, but in that case, should the package be renamed to python-xpra since the python modules will be public ? Or can the package still keep the name 'xpra' ? That should be fine but please don't take my words as granted. :) At the moment I can't recall a good example but there are some exceptions like when package in mainly used as application. Proves nothing but worth noticing that Ruby packaging team has the following naming guideline: If the package is mainly used as an application (not as a library), then it can be named foo. But IMHO that's common sense. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209190300.24916.only...@member.fsf.org
Re: Xpra to publicly expose its modules
On 18 September 2012 18:00, Dmitry Smirnov only...@member.fsf.org wrote: At the moment I can't recall a good example but there are some exceptions like when package in mainly used as application. IPython is packaged as 'ipython', 'ipython3', etc., and it also includes a public module. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOvn4qgoh_wUN_jSG8teDoFXe3ykxFdpjTv6mh2BoyrGau_=m...@mail.gmail.com
Re: Xpra to publicly expose its modules
On Sep 18, 2012, at 05:23 PM, أحمد المحمودي wrote: On Tue, Sep 18, 2012 at 06:27:21PM +1000, Dmitry Smirnov wrote: Although Xpra is mainly an application its modules can be used by frontends like winswitch, packaged by yours truly. In particular winswitch have an ugly workaround [1] to find private Xpra modules. This is something upstream already complained to me about. ---end quoted text--- Ok, but in that case, should the package be renamed to python-xpra since the python modules will be public ? Or can the package still keep the name 'xpra' ? Does it make any sense to split the source package into multiple binary packages? Then the library bits would live in python-xpra (and maybe someday, python3-xpra wink) and the program part would live in xpra. Cheers, -Barry signature.asc Description: PGP signature
Re: Xpra to publicly expose its modules
On Wed, 19 Sep 2012 03:21:14 Barry Warsaw wrote: Does it make any sense to split the source package into multiple binary packages? Then the library bits would live in python-xpra (and maybe someday, python3-xpra wink) and the program part would live in xpra. One day it could be done (perhaps when upstream introduce support for python3) but IMHO at this time it doesn't worth it. Executable part would then have just 3-lines wrapper script and hard dependency on exact library version... Also we will need * to think about which package config files should go. * to think about which package should ship arch-indep files in /usr/share/xpra * to find a sponsor for splitted package. Considering there are some examples of application/library packages shipped by one package I believe we can consider splitting later, if necessary. I just recalled another example of package shipping executables and libraries: mysql-utilities, but this may be not a good example because mysql-utilities might need to be splitted too. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209191112.46296.only...@member.fsf.org
