Re: [Python-modules-team] RM of shiboken & pyside ?
Hi Didier and Scott, On July 6, 2016 7:32:22 AM GMT+03:00, Scott Kittermanwrote: > On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote: > > Hi there, > > > > Now that we have PyOtherSide in Debian, and that both shiboken and > > PySide are somewhat broken in sid & stretch; what about just > removing > > them from Debian ? > > > > I'm not a PySide user myself, and it's abandonned upstream… > > If it's dead, let's remove it. > > Scott K It is not dead according to Git activity: https://code.qt.io/cgit/pyside/shiboken.git/ https://code.qt.io/cgit/pyside/pyside.git/ PyOtherSide is a project with different functionality, so having it is not a reason for removing PySide. However we have PyQt5, and that can count as such reason. -- Dmitry Shachnev
Re: [Python-modules-team] RM of shiboken & pyside ?
On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote: > Hi there, > > Now that we have PyOtherSide in Debian, and that both shiboken and > PySide are somewhat broken in sid & stretch; what about just removing > them from Debian ? > > I'm not a PySide user myself, and it's abandonned upstream… If it's dead, let's remove it. Scott K
Re: Python package providing both modules and an app
On 07/05/2016 04:47 PM, Hugo Lefeuvre wrote: > Hi Thomas, > >> I did lots of that in OpenStack. You can have a look at one of our tool >> to handle the dh_auto_install for Python: >> >> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install >> >> The way to use it in your debian/rules file is to do: >> pkgos-alternative slugify slugify >> >> [ this tool is available at: >> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/misc/pkgos-alternative-bin >> ] >> >> then simply do: >> >> override_dh_auto_install: >> pkgos-dh_auto_install >> >> and that's it, it will handle the /usr/bin/python{3,}-slugify >> alternative implementations for you. > > That looks very interesting ! > > However, I have to say I'm a bit reluctant to make the package depend on a > supplementary Build-Dependency only in order to prettify debian/rules. You don't have to do that. You can open pkgos-dh_auto_install, see what it does, and pickup ideas there. It's only 10 lines of shell scripts, and you probably don't even need everything that's inside. Cheers, Thomas Goirand (zigo)
Re: Removing me from Uploader field of html5lib
On Jul 04, 2016, at 04:52 PM, Olivier Berger wrote: >Unfortunately, I'm no longer able to dedicate time to help maintaining >the html5lib package. Thanks so much for your past work on it! >Thus I'm requesting that anyone uploading the next version as part of >the team, please remove me from the uploaders field. Done in vcs. If it's okay with you, I'll hold off doing a new upload until there's a new upstream. >Btw, the docs on the wiki documents how to be added/contribue, but not >really how to stop ;-) Despite that, you figured it out. :) Cheers, -Barry
Re: Python package providing both modules and an app
On 06/22/2016 09:51 PM, Hugo Lefeuvre wrote: > Hi Ben, > >>> The package is originally requested as a Python module[2] and it seems >>> clear to me that the whole thing is only useful as a library >> >> I don't understand this statement. If it is *only* useful as a library, >> why install the command-line entry point? > > Indeed, I though about that, but python-slugify has been developed as an > application[0] so I think it's rather a bad idea to completely ignore the > entry point, even if it's not really useful. I think upstream would disagree, > too. In my opinion, better build a third package, even if it won't be used > a lot. The 3rd package is mandatory if your package needs to store config files. Cheers, Thomas
Re: Python package providing both modules and an app
On 06/21/2016 11:13 PM, Hugo Lefeuvre wrote: > Hi all ! > > I'm currently packaging python-slugify[0], a Python application for > slugifying unicode strings. Like here[1] upstream decided to write > everything as a python module with an entry script placed in /usr/bin > that calls main(). So we can consider python-slugify as both an application > and a library. > > The package is originally requested as a Python module[2] and it seems > clear to me that the whole thing is only useful as a library, so I've > named the source package 'python-slugify'. It provides following packages: > * 'python-slugify' (Python 2 lib), > * 'python3-slugify' (Python 3 lib), > * 'slugify' (ships the entry script[3], depends on python3-slugify). > > Everything is working well. However, I'm not really satisfied by the way I > solved the problem in debian/rules[4]. Does anybody know a better way > of doing that ? > > Cheers, > Hugo Hugo, I did lots of that in OpenStack. You can have a look at one of our tool to handle the dh_auto_install for Python: http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install The way to use it in your debian/rules file is to do: pkgos-alternative slugify slugify [ this tool is available at: http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/misc/pkgos-alternative-bin ] then simply do: override_dh_auto_install: pkgos-dh_auto_install and that's it, it will handle the /usr/bin/python{3,}-slugify alternative implementations for you. I hope that helps, Cheers, Thomas Goirand (zigo)