Re: Terminal Pager at unit tests
* Josue Ortega , 2014-09-08, 21:21: When the tests are running the docstrings are displayed in a terminal pager making impossible run all tests without human interaction to close the pager. I've found this really annoying if someone wants to build the package even the build process might fail if it's running on an automated enviroment. I could't find an elegant way to disable the terminal pager. Programs launching pagers must honour the PAGER environment variable (see Policy §11.4). So adding this to debian/rules should do the trick: export PAGER = cat -- Jakub Wilk -- 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/20140909105957.ga3...@jwilk.net
Re: Terminal Pager at unit tests
On Tue, Sep 9, 2014 at 4:59 AM, Jakub Wilk wrote: > * Josue Ortega , 2014-09-08, 21:21: > >> When the tests are running the docstrings are displayed in a terminal >> pager making impossible run all tests without human interaction to close >> the pager. I've found this really annoying if someone wants to build the >> package even the build process might fail if it's running on an automated >> enviroment. I could't find an elegant way to disable the terminal pager. >> > > Programs launching pagers must honour the PAGER environment variable (see > Policy §11.4). So adding this to debian/rules should do the trick: > > export PAGER = cat > > -- > Jakub Wilk > > > -- > 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/20140909105957.ga3...@jwilk.net > > Thanks Jakub!! -- Josue Ortega Happy Hacking http://josueortega.org PGP key 4096R/AB4AFD3F 2012-08-20 Fingerprint = 7733 B328 D279 5F5B E232 5ADD 0150 9D5C AB4A FD3F
When packaging a library, should I prevent its test suite from being packaged
I'm packaging a Python3-only library, PyMySQL [1], for internal usage, chiefly using dh $@ --with python3 --buildsystem=pybuild This library includes a test suite, in a subdirectory named "tests", within its source tree. This directory gets packaged, installed and byte-compiled (by the generated postinst script) during the installation. Having the test suite packaged along with the code looks like having not much sense to me, so should I try to exclude this subdirectory from packaging? Is it considered a bad practice? I don't have much familiarity with Python, let alone packaging its libraries, so I'm not sure if removing such files will break the library or not and what seasoned Python packagers do in cases like this. Please CC me as I'm not subscribed. 1. https://pypi.python.org/pypi/PyMySQL -- 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/20140909185320.89183bfff8ff6a48ebdbb...@domain007.com
Re: When packaging a library, should I prevent its test suite from being packaged
On Sep 09, 2014, at 06:53 PM, Konstantin Khomoutov wrote: >Having the test suite packaged along with the code looks like having >not much sense to me, so should I try to exclude this subdirectory from >packaging? Is it considered a bad practice? I'm not sure there's consensus on this, so I will just say that I usually don't bother removing the test directory, especially if it is within the package namespace (IOW, under the main package's top-level directory). A well written package should not *require* the test directory (i.e. it should not break if it's removed), but it also should do no harm to just leave it there. IMHO, I think they can be a good thing to include, as it can allow for installed package tests (both by the end user and DEP-8), and can serve as a learning experience for users. It's often more work to remove them too, and who likes to do extra unnecessary work? :) One thing I have *occasionally* done is to segregate the test subdirectory to a -dev package, but that's only in special circumstances, e.g. where the package is intended for environments with *very* tight constraints like mobile flavors. Cheers, -Barry -- 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/20140909112125.23ca5...@anarchist.wooz.org
Re: When packaging a library, should I prevent its test suite from being packaged
[Konstantin Khomoutov, 2014-09-09]
> This library includes a test suite, in a subdirectory named "tests",
> within its source tree. This directory gets packaged, installed and
> byte-compiled (by the generated postinst script) during the
> installation.
>
> Having the test suite packaged along with the code looks like having
> not much sense to me, so should I try to exclude this subdirectory from
> packaging? Is it considered a bad practice? I don't have much
> familiarity with Python, let alone packaging its libraries, so I'm not
> sure if removing such files will break the library or not and what
> seasoned Python packagers do in cases like this.
if it is installed as .../dist-packages/tests, then remove¹ it and
report bug upstream (to move it to pymysql/tests)
(I will remove all .../dist-packages/test{,s} by default in next
dh_python{2,3} version).
If it is installed as .../dist-packages/pymysq/tests and doesn't contain
anything other than .py files, then leave it. It will be useful while
running runtime tests (f.e. in autopkgtest)
[¹] export PYBUILD_AFTER_INSTALL=rm -r {install_dir}/tests
> Please CC me as I'm not subscribed.
--
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/20140909152825.gy4...@sts0.p1otr.com
Re: When packaging a library, should I prevent its test suite from being packaged
On 9 September 2014 16:53, Konstantin Khomoutov wrote: > Having the test suite packaged along with the code looks like having > not much sense to me, so should I try to exclude this subdirectory from > packaging? Is it considered a bad practice? I don't have much > familiarity with Python, let alone packaging its libraries, so I'm not > sure if removing such files will break the library or not and what > seasoned Python packagers do in cases like this. As a Python /user/, I would very much like it for the tests to be installed along with a package when possible; this allows me to run the tests on a particular system in order to verify that the installation of the package is fully functional. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- 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/camckhmq_wprhdygjtn-bzfxm2b9l6zpmk+tmuoa_q1scyt1...@mail.gmail.com
Re: When packaging a library, should I prevent its test suite from being packaged
On Tue, 9 Sep 2014 17:28:25 +0200
Piotr Ożarowski wrote:
> [Konstantin Khomoutov, 2014-09-09]
> > This library includes a test suite, in a subdirectory named "tests",
> > within its source tree. This directory gets packaged, installed and
> > byte-compiled (by the generated postinst script) during the
> > installation.
> >
> > Having the test suite packaged along with the code looks like having
> > not much sense to me, so should I try to exclude this subdirectory
> > from packaging? Is it considered a bad practice? I don't have much
> > familiarity with Python, let alone packaging its libraries, so I'm
> > not sure if removing such files will break the library or not and
> > what seasoned Python packagers do in cases like this.
>
> if it is installed as .../dist-packages/tests, then remove¹ it and
> report bug upstream (to move it to pymysql/tests)
> (I will remove all .../dist-packages/test{,s} by default in next
> dh_python{2,3} version).
>
> If it is installed as .../dist-packages/pymysq/tests and doesn't
> contain anything other than .py files, then leave it. It will be
> useful while running runtime tests (f.e. in autopkgtest)
The library appears to be well-behaving and installs its tests under
its own directory, that is, in .../dist-packages/pymysq/tests.
> [¹] export PYBUILD_AFTER_INSTALL=rm -r {install_dir}/tests
Thanks, that worked.
But based on the insight provided by you and others, I'm inclined to
revert this change and let the test files be installed.
One minor thing remains with this test suite though: after fixing it to
work with Python 3.2 (Wheezy's; the test suite uses those u"" no-op
prefixes for some Unicode literals, which were not present in 3.2) I
have discovered the tests attempt to connect to a MySQL instance on
the localhost, and authenticate there as the user "root" using no
password. So it seems that the test suite either expects a certain
setup to be present to have a sensible run or has some knobs for the
user to tweak up front... What I'm leading to, it that in the
library's present state, it's hard to decide whether these tests are
really useful because you can't "just run" them. I understand that
this is a rather philosophical question though so I'm communicating
this mostly for amusement.
Thanks to all who replied!
--
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/20140909203949.72f387c24308620625a65...@domain007.com
django / python-mysql.connector / python2 / unicode broken
See: https://code.djangoproject.com/ticket/22377 http://bugs.mysql.com/bug.php?id=73867 I will wait and see if I get any response to the above bug reports, otherwise I will upload python-mysql.connector with a fix I gave in the later bug report. Think this might have been a problem for Django1.6, I only have tested 1.7 myself. -- Brian May
