Re: When packaging a library, should I prevent its test suite from being packaged
Hi, Konstantin Khomoutov: > have discovered the tests attempt to connect to a MySQL instance on > the localhost, and authenticate there as the user "root" using no > password. I would file an Upstream bug for this. They should use a "test" user with a "test_PACKAGENAME" database, and make the mysql credentials overrideable (via environment or whatever). Requiring (a) root (b) without a password (c) on localhost (presumably) is a bad idea on all three counts. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910090429.ga21...@smurf.noris.de
Help with old mathplotlib API (nxutils) needed
Hi, I'm trying to upgrade dicompyler[1] but I seem to have some final problem: $ dicompyler Traceback (most recent call last): File "/usr/share/dicompyler/dicompyler_app.py", line 10, in import dicompyler.main File "/usr/share/dicompyler/__init__.py", line 10, in from main import start, __version__ File "/usr/share/dicompyler/main.py", line 25, in from dicompyler import dicomgui, dvhdata, dvhdoses, dvhcalc File "/usr/share/dicompyler/dvhcalc.py", line 15, in import matplotlib.nxutils as nx ImportError: No module named nxutils A web search uncovered that nxutils was deprecated and (to) quickly removed but since it is used only at two places in the code: $ grep -R nx dicompyler/dvhcalc.py:import matplotlib.nxutils as nx dicompyler/dvhcalc.py:if nx.pnpoly(point[0], point[1], dicompyler/dvhcalc.py:grid = nx.points_inside_poly(dosegridpoints, contour) it might be simple to replace for somebody who previously dealt with mathplotlib. BTW, as I previously wrote here on this list[2] I'm afraid I did not found a clever solution to package this Python application. I learned here on this list that applications should go to /usr/share/ but I needed to set PYTHONPATH in a wrapper to make this working and I have the strong feeling that my packaging is not very sensible and the files should rather go to some better place. Any comments about this are welcome as well. Any help would be appreciated Andreas. [1] svn://anonscm.debian.org/debian-med/trunk/packages/dicompyler/trunk/ [2] https://lists.debian.org/debian-python/2014/08/msg00146.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910133523.gi18...@an3as.eu
Python applications: private dirs and PYTHONPATH issue
[Andreas Tille, 2014-09-10] > BTW, as I previously wrote here on this list[2] I'm afraid I did not > found a clever solution to package this Python application. I learned > here on this list that applications should go to /usr/share/ > but I needed to set PYTHONPATH in a wrapper to make this working and I > have the strong feeling that my packaging is not very sensible and the > files should rather go to some better place. Any comments about this > are welcome as well. if you install your script to the same directory as the application¹ then all you need is `dh_link /usr/bin/foo /usr/share/pkgname/foo` in debian/rules or adequate line in debian/pkgname.links file. No need to write wrappers that set PYTHONPATH, etc. [¹] pybuild exmaple: export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/pkgname/ --install-scripts=/usr/share/pkgname -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910140340.gc4...@sts0.p1otr.com
Re: Python applications: private dirs and PYTHONPATH issue
[Piotr Ożarowski, 2014-09-10] > all you need is `dh_link /usr/bin/foo /usr/share/pkgname/foo` in or even `dh_link /usr/share/pkgname/foo /usr/bin/foo` :) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910140840.gd4...@sts0.p1otr.com
Re: When packaging a library, should I prevent its test suite from being packaged
On 9 September 2014 09:28, Piotr Ożarowski wrote:
> (I will remove all .../dist-packages/test{,s} by default in next
> dh_python{2,3} version).
Does this mean we'll get a nice warning too, so we know that we need
to report the bug upstream? :)
♥,
- Tianon
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cahnknk3dx4zbiwqflektrvkl_0j0_ktuj7cz-pcxnkqj5zs...@mail.gmail.com
Re: Python applications: private dirs and PYTHONPATH issue
Hi Piotr,
On Wed, Sep 10, 2014 at 04:03:40PM +0200, Piotr Ożarowski wrote:
>
> if you install your script to the same directory as the application¹ then
> all you need is `dh_link /usr/bin/foo /usr/share/pkgname/foo` in
> debian/rules or adequate line in debian/pkgname.links file.
> No need to write wrappers that set PYTHONPATH, etc.
>
> [¹] pybuild exmaple:
> export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/pkgname/
> --install-scripts=/usr/share/pkgname
If I try this
$ svn diff
Index: rules
===
--- rules (Revision 17978)
+++ rules (Arbeitskopie)
@@ -8,14 +8,16 @@
DEBPKGNAME := $(shell dpkg-parsechangelog | awk '/^Source:/ {print $$2}')
+export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/dicompyler/
--install-scripts=/usr/share/dicompyler
+
%:
dh $@ --with python2 --buildsystem=pybuild
override_dh_install:
- mkdir -p debian/$(DEBPKGNAME)/usr/share/$(DEBPKGNAME)
- mv debian/$(DEBPKGNAME)/usr/lib/python*/dist-packages/$(DEBPKGNAME)
debian/$(DEBPKGNAME)/usr/share/$(DEBPKGNAME)
+# mkdir -p debian/$(DEBPKGNAME)/usr/share/$(DEBPKGNAME)
+# mv debian/$(DEBPKGNAME)/usr/lib/python*/dist-packages/$(DEBPKGNAME)
debian/$(DEBPKGNAME)/usr/share/$(DEBPKGNAME)
dh_install
- rm -rf debian/$(DEBPKGNAME)/usr/lib
+# rm -rf debian/$(DEBPKGNAME)/usr/lib
I get:
...
Copying dicompyler.egg-info to
/tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler/dicompyler-0.4.2.egg-info
running install_scripts
Installing dicompyler script to
/tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler
error: [Errno 21] Is a directory:
'/tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler/dicompyler'
E: pybuild pybuild:256: install: plugin distutils failed with: exit code=1:
/usr/bin/python setup.py install --root
/tmp/buildd/dicompyler-0.4.2/debian/dicompyler
--install-lib=/usr/share/dicompyler/ --install-scripts=/usr/share/dicompyler
dh_auto_install: pybuild --install -i python{version} -p 2.7 --dir . --dest-dir
/tmp/buildd/dicompyler-0.4.2/debian/dicompyler returned exit code 13
debian/rules:14: recipe for target 'binary' failed
make: *** [binary] Error 13
I have tried this before but due to this failure I decided for manual
moving. Is this a bug in pybuild or did I simply something wrong?
I can confirm that linking the app works if (and only if) I put the
modules into /usr/share/dicompyler/dicompyler (as can be seen in current
SVN).
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910164040.gc19...@an3as.eu
Re: Python applications: private dirs and PYTHONPATH issue
[Andreas Tille, 2014-09-10]
> Copying dicompyler.egg-info to
> /tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler/dicompyler-0.4.2.egg-info
> running install_scripts
> Installing dicompyler script to
> /tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler
> error: [Errno 21] Is a directory:
> '/tmp/buildd/dicompyler-0.4.2/debian/dicompyler/usr/share/dicompyler/dicompyler'
> E: pybuild pybuild:256: install: plugin distutils failed with: exit code=1:
> /usr/bin/python setup.py install --root
> /tmp/buildd/dicompyler-0.4.2/debian/dicompyler
> --install-lib=/usr/share/dicompyler/ --install-scripts=/usr/share/dicompyler
> dh_auto_install: pybuild --install -i python{version} -p 2.7 --dir .
> --dest-dir /tmp/buildd/dicompyler-0.4.2/debian/dicompyler returned exit code
> 13
> debian/rules:14: recipe for target 'binary' failed
> make: *** [binary] Error 13
>
> I have tried this before but due to this failure I decided for manual
> moving. Is this a bug in pybuild or did I simply something wrong?
ah, module name and script name is the same, try this instead:
export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/dicompyler/
export PYBUILD_AFTER_INSTALL=mv {destdir}/usr/bin/dicompyler
{destdir}/usr/share/dicompyler/run
and symlink /usr/share/dicompyler/run to /usr/bin/dicompyler
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910170937.ge4...@sts0.p1otr.com
Re: When packaging a library, should I prevent its test suite from being packaged
[Tianon Gravi, 2014-09-10]
> On 9 September 2014 09:28, Piotr Ożarowski wrote:
> > (I will remove all .../dist-packages/test{,s} by default in next
> > dh_python{2,3} version).
>
> Does this mean we'll get a nice warning too, so we know that we need
> to report the bug upstream? :)
yes (and I'm still wondering if failing with an error message that this
module name is too generic is a better idea)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910171113.gf4...@sts0.p1otr.com
Re: When packaging a library, should I prevent its test suite from being packaged
On 10 September 2014 11:11, Piotr Ożarowski wrote: > yes (and I'm still wondering if failing with an error message that this > module name is too generic is a better idea) I'd personally love to see it hard fail (since warnings will be quite often missed), especially if it included some hints about how to patch it out or patch move it appropriately while waiting for upstream to respond to the request to install it in the proper namespace. ♥, - Tianon -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahnknk3kxgazquj2atokt1wrcpvgqoufww8ntmq0crweh4e...@mail.gmail.com
Re: Help with old mathplotlib API (nxutils) needed
The mathplotlib API changes document recommends switching from matplotlib.nxutils to matplotlib.path.Path.contains_point and friends. http://matplotlib.org/api/api_changes.html#id1 Also I used codesearch.d.n and found some code which supports both versions of the mathplotlib API: http://sources.debian.net/src/psychopy/1.79.00+git16-g30c9343.dfsg-1/psychopy/visual/helpers.py#L41 http://sources.debian.net/src/psychopy/1.79.00+git16-g30c9343.dfsg-1/psychopy/visual/helpers.py#L362 http://sources.debian.net/src/psychopy/1.79.00+git16-g30c9343.dfsg-1/psychopy/visual/helpers.py#L405 -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6H9WJ8gp-0UVxgD6GwYa=ns_1slx3zicboucmbnq0q...@mail.gmail.com
Re: Help needed to test packages with Django 1.7
On 7 August 2014 10:19, Brian May wrote: > virtualenv --system-site-packages ~/old_django > . ~/old_django/bin/activate > pip install django==1.6.5 > pip install django-south > django-admin --settings=??? migrate --all > Calling django-admin like that won't use the virtualenv. > touch /etc/xyz/south_migrations_complete > deactivate > rm -rf ~/old_django > Latest version of this: === cut === #!/bin/sh set -ex TMPDIR=$(mktemp -d) trap "rm -rf -- '$TMPDIR'" EXIT HUP INT TERM virtualenv --system-site-packages "$TMPDIR" . "$TMPDIR/bin/activate" pip install django==1.6.5 pip install south python /usr/bin/django-admin -smyapp.settings migrate "$@" === cut === Note that I have explicitly called python. This ensures Python 3 not used (not supported by South + the virtualenv is Python 2 only) and that we get the python from the virtualenv. I have tested this and it appears to work, although the above was changed not to be specific to my app. -- Brian May
Re: Help needed to test packages with Django 1.7
Hi Brian, thanks for those investigations! On Thu, 11 Sep 2014, Brian May wrote: > Note that I have explicitly called python. This ensures Python 3 not used > (not supported by South + the virtualenv is Python 2 only) and that we get > the python from the virtualenv. > > I have tested this and it appears to work, although the above was changed > not to be specific to my app. Please document this in python-django's README.Debian and mention where to find this sample in the current debian/python-django.NEWS entry. TIA. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911062808.gb9...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
On 11 September 2014 16:28, Raphael Hertzog wrote: > Please document this in python-django's README.Debian and mention where to > find this sample in the current debian/python-django.NEWS entry. > Ok, will look into this tomorrow. Also noticed that /usr/bin/django-admin has Python 2.6 stuff that is no longer relevant, as Python2.6 isn't supported any more. Will remove this too. -- Brian May
