Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 17:12 Robert Collins wrote: > > Presumably > https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests > would be the intent? > Blah. I always have this this debate with myself if I should download the orig.tar.gz from github or from pypi. Sometimes pypi is missing files like this, in other cases github has non-DFSG free files that I can't package, which aren't in the pypi version. Maybe in this case I should file a bug report however. > The tarball on PyPI is missing it - so I think its a broken > MANIFEST.in - it hasn't been updated to include the tests. > I am still confused - why is it even trying to run tests if they don't exist in my version?
python3-cairo-dbg missing
Hi, I'm trying to debug Pitivi's Gtk Python3 app but I cannot because python3.4dm cannot import cairo: $ python3.4dm -c "import cairo" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/cairo/__init__.py", line 18, in from ._cairo import * ImportError: No module named 'cairo._cairo' This is because the cairo module uses an .so library: $ ls /usr/lib/python3/dist-packages/cairo/*.so _cairo.cpython-34m-x86_64-linux-gnu.so I see for python-cairo there is python-cairo-dbg, but for python3-cairo there is no python3-cairo-dbg. Could you please create one which provides the debug version of the cairo module? (Should I file a bug to keep track of this? Where?) Thanks, Alex
Re: Python < 3.5 tests
Hi all, On Thu, 8 Oct 2015 08:12:22 +1100, Brian May wrote: [...] > So it looks like it can't find the tests under Python 2.7 or Python 3.4, > so it use to work, however under Python 3.5 it now does find the tests > and they fail. > > This left me wondering: > > * Why does it not find the tests under Python 2.7, 3.4? What is > different about Python 3.5 that it does? There was a change in unittest autoloader in Python 3.5. It now tries to import the package even if it has no tests. I do not know if it is an intended change, or a side-effect of fixing some bug ([1]?). Maybe Robert can enlighten us here. This has caused some my packages to FTBFS too, for example see bugs #800671 and #800139. So if it not an intended change, it should be fixed upstream. [1] http://bugs.python.org/issue22457 > * Why is Python 3.4 still relevant? Hasn't 3.5 replaced 3.4? Why is it > being tested by pybuild? Python 3.4 is still the default version in Debian. We can't do the switch at once, so the transition is split into three steps: 1) Add Python 3.5; 2) Make 3.5 the default; 3) Remove Python 3.4. We are currently in the end of first step, AFAIK. And Python 3.4 will be removed only when all three steps are finished. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Python < 3.5 tests
On Oct 08, 2015, at 11:15 AM, Brian May wrote: >Maybe in this case I should file a bug report however. I do this when the PyPI tarball is missing some important file or directory. Fortunately the upstreams I've done this with have generally been very responsive about fixing the problem and doing a new release. On rare occasions as a temporary workaround, I grab the missing file from their vcs and arrange to have it installed properly during package build. Cheers, -Barry
Re: Git migration schedule
Hi Brian (2015.10.06_02:29:35_+0200) > Thinking it might be good to have a list somewhere of packages that should > get manually checked (and where this hasn't happened yet) after the > migration is complete. Otherwise we might all assume somebody else has > checked a package, and it gets forgotten. Yeah, I'd like us to quickly sprint through them, too. > Just one problem(?) I do see, some of the commits corresponding to patches > have the following committer: > > Stefano Rivera ... > Suspect it might be a default used because there was no author information > in the original debian/patches/* file. Good catch. I think I fixed that in a652cb2 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Git migration schedule
Hi Barry (2015.10.02_16:24:28_+0200) > 8-Oct - Assuming no objections or showstoppers, turn off write access to all > of DPMT svn. Done. And kicking off the migration now... SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#801334: ITP: pypi2deb -- PyPI to Debian converter
Package: wnpp Severity: wishlist Owner: Piotr Ożarowski * Package name: pypi2deb Version : 1.20151008 Upstream Author : Piotr Ożarowski * URL : https://github.com/p1otr/pypi2deb * License : Expat Programming Lang: Python Description : PyPI to Debian converter This package provides: * py2dsp - converts PyPI package to Debian source package * pypi2debian - converts PyPI repository to Debian repository . Features: * uses PyPI metadata * supports Python 2.X, 3.X and PyPy * guesses build dependencies * reuses existing Debian package names if already packaged in Debian * creates -doc package with Sphinx regenerated documentation * generates ITP email template * easy to customise (profiles, overrides, templates) * uses Debian tools to generate files if possible * integrates with dh-python's tools * asynchronous signature.asc Description: PGP signature
Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 22:44 Dmitry Shachnev wrote: > > There was a change in unittest autoloader in Python 3.5. It now tries to > import the package even if it has no tests. I do not know if it is an > intended change, or a side-effect of fixing some bug ([1]?). Maybe Robert > can enlighten us here. > Right. I think somebody else said the same thing, however I didn't understand how it could be related. My (unproven) theory is it is importing ajax_select/__init__.py, which in turn loads Django files, which in turn fail because Django is not initialized. I seem to have this problem regularly. What is a good way of initializing Django for the tests? My latest technique - IIRC - create a wrapper python code for the the tests, and called it debian/run_tests.py - along with a debian/test_settings.py file - is this the best way? Example: http://anonscm.debian.org/viewvc/python-modules/packages/djangorestframework/trunk/debian/run_tests.py?revision=33810&view=markup http://anonscm.debian.org/viewvc/python-modules/packages/djangorestframework/trunk/debian/test_settings.py?revision=33810&view=markup > This has caused some my packages to FTBFS too, for example see bugs > #800671 and #800139. So if it not an intended change, it should be fixed > upstream. > > [1] http://bugs.python.org/issue22457 > I just noticed #800137 - I think I have seen this exact same problem here too.
Re: Python < 3.5 tests
On 9 October 2015 at 00:43, Dmitry Shachnev wrote: > Hi all, > > On Thu, 8 Oct 2015 08:12:22 +1100, Brian May wrote: > [...] >> So it looks like it can't find the tests under Python 2.7 or Python 3.4, >> so it use to work, however under Python 3.5 it now does find the tests >> and they fail. >> >> This left me wondering: >> >> * Why does it not find the tests under Python 2.7, 3.4? What is >> different about Python 3.5 that it does? > > There was a change in unittest autoloader in Python 3.5. It now tries to > import the package even if it has no tests. I do not know if it is an > intended change, or a side-effect of fixing some bug ([1]?). Maybe Robert > can enlighten us here. Imagine I have a directory with __init__.py and test_foo.py, and a subdir (sub) of that with __init__.py and test_bar.py. Before that change, __init__ was loaded and test_foo was loaded. and sub/__init__ was loaded, then if present the load_tests hook in sub/__init__ is fire, and finally test_bar.py is loaded. After the change the root __init__ is examined for a load_tests hook as well. So the only time this specific patch would change behaviour is if discover's start dir was a package (vs a namespace package aka directory) and __init__ has a load_tests hook. As discover is being run with a start of ., thats not the impact here. But - ajax_select/__init__.py is going to be imported, and thats whats erroring. I don't think that this is a 3.5 unit testing change - I think its an error importing some bit of django. The test suite output should show the actual import error exception, whats been pasted here so far has just been the loader stage output, but the loader returns a thunk that will show the exception that occurred during loading and would help debugging. > This has caused some my packages to FTBFS too, for example see bugs > #800671 and #800139. So if it not an intended change, it should be fixed > upstream. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800671 shows this: "/tmp/buildd/python-changelog-0.3.4/.pybuild/pythonX.Y_3.5/build/changelog/__init__.py", line 3, in from .changelog import setup File "/tmp/buildd/python-changelog-0.3.4/.pybuild/pythonX.Y_3.5/build/changelog/changelog.py", line 5, in from sphinx.util.compat import Directive ImportError: No module named 'sphinx' And pybuild has cd'd to the build dir there before running discover. So - changelog's __init__ can't be imported - that should occur in all versions of discover, when changelog is imported and scanned, because importing anything from within it will need to initialise the package first, which is basic Python semantics. 800139 has the same issue. Any tests of these packages will need to import the package itself to exercise it, so I don't see a CPython/discover bug here. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 22:44 Dmitry Shachnev wrote: > Python 3.4 is still the default version in Debian. We can't do the switch > at once, so the transition is split into three steps: > > 1) Add Python 3.5; > 2) Make 3.5 the default; > 3) Remove Python 3.4. > > We are currently in the end of first step, AFAIK. And Python 3.4 will > be removed only when all three steps are finished. > Ok, so I guess this means some packages (at the moment) will run tests against Python 3.5, but some won't. What is the best way of calling unittest2 from debian/rules? Is the following - which I suspect won't use Python 3.5 until it becomes the default - OK, or should I try to do something that iterates over all Python versions? override_dh_auto_test: python -m unittest2 discover -v python3 -m unittest2 discover -v (also somebody said "python -m unittest2.discover" however I found that didn't work)
Re: Python < 3.5 tests
On Oct 08, 2015, at 09:19 PM, Brian May wrote:
>What is the best way of calling unittest2 from debian/rules?
For --buildsystem=pybuild, I've done this:
override_dh_auto_test:
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} -m nose2 -vv" \
dh_auto_test
Should be easy to tweak for your case.
Cheers,
-Barry
Re: Python < 3.5 tests
On Fri, 9 Oct 2015 at 08:16 Robert Collins wrote: > But - ajax_select/__init__.py is going to be imported, and thats whats > erroring. I don't think that this is a 3.5 unit testing change - I > think its an error importing some bit of django. > Except there is no errors under Python2.7. If Python2.7 or Python3.4 loaded ajax_select/__init__.py I would expect to see exactly the same Django error. To test this out, I just put "raise RuntimeError()" into ajax_select/__init__.py I get the same results for Python2.7 and Python3.4, however Python3.5 generates the exception. So it does seem like it really is the case that Python3.5 now loads ajax_select/__init__.py when no tests exist, when this previously didn't happen. Bug #800137 is a complication. Am seriously thinking maybe we should backport the change (a very simple change) into our version of Django.
Re: Python < 3.5 tests
On Fri, 9 Oct 2015 at 08:16 Robert Collins wrote: > But - ajax_select/__init__.py is going to be imported, and thats whats > erroring. I don't think that this is a 3.5 unit testing change - I > think its an error importing some bit of django. > On 2nd thoughts, I didn't really read that properly - thought you were disagreeing, when in actual fact we seem to be agreeing. Ooops. Sorry about this.
Re: Python < 3.5 tests
On 9 October 2015 at 10:40, Brian May wrote: > On Fri, 9 Oct 2015 at 08:16 Robert Collins > wrote: >> >> But - ajax_select/__init__.py is going to be imported, and thats whats >> erroring. I don't think that this is a 3.5 unit testing change - I >> think its an error importing some bit of django. > > > Except there is no errors under Python2.7. If Python2.7 or Python3.4 loaded > ajax_select/__init__.py I would expect to see exactly the same Django error. Right - and if there are any tests they will need to load that :) The reason it's being discovered is likely due to the pattern bugfix (also in 3.5) - previously discover couldn't handle directories with names tht didn't match the file pattern - and that meant nested test suites didn't load right. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
[Barry Warsaw, 2015-10-08]
> For --buildsystem=pybuild, I've done this:
>
> override_dh_auto_test:
> PYBUILD_SYSTEM=custom \
> PYBUILD_TEST_ARGS="{interpreter} -m nose2 -vv" \
> dh_auto_test
override_dh_auto_test:
dh_auto_test -- --system=custom --test-args="{interpreter} -m nose2 -vv"
if you want to keep it shorter
--
evil general Piotr
Re: Python < 3.5 tests
On Oct 08, 2015, at 11:53 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2015-10-08]
>> For --buildsystem=pybuild, I've done this:
>>
>> override_dh_auto_test:
>> PYBUILD_SYSTEM=custom \
>> PYBUILD_TEST_ARGS="{interpreter} -m nose2 -vv" \
>> dh_auto_test
>
>override_dh_auto_test:
> dh_auto_test -- --system=custom --test-args="{interpreter} -m nose2 -vv"
>
>if you want to keep it shorter
Thanks! I cut-n-pasted that from an older packaging example.
Cheers,
-Barry
Re: Python < 3.5 tests
On Fri, 9 Oct 2015 at 08:49 Robert Collins wrote: > The reason it's being discovered is likely due to the pattern bugfix > (also in 3.5) - previously discover couldn't handle directories with > names tht didn't match the file pattern - and that meant nested test > suites didn't load right. > I get the impression that this new behaviour is intended, and here to stay. I am happy with this.
Re: Git migration schedule
On Fri, 9 Oct 2015 at 02:06 Stefano Rivera wrote: > Done. And kicking off the migration now... > Great! Will the migration do packages like python-django? Just thinking that python-django in subversion is old, and the version in git doesn't (yet) use git-dpm; you don't want the migration changing the existing python-django git by mistake. I am not sure what the plan is for the location for the final migration run. I suspect there are other packages that will be in a similar situation.
Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 17:12 Robert Collins wrote: > Presumably > https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests > would be the intent? > That is the develop branch. So not in any released version, which is the master branch. The develop branch is missing the files in MANIFEST.in, so I filled a bug report anyway. https://github.com/crucialfelix/django-ajax-selects/issues/136
Re: Python < 3.5 tests
On Fri, 9 Oct 2015 at 17:22 Brian May wrote: > That is the develop branch. So not in any released version, which is the > master branch. > The tests at the moment are somewhat useless too, still need to be written. Think the best solution at the moment (unfortunately) is just to disable the tests until upstream release a version with good working tests. There doesn't seem to be much point fixing problems with the tests when there aren't any tests anyway.
Bug#801366: ITP: notebook -- Jupyter interactive notebook
Package: wnpp Owner: Julien Puydt Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: notebook Version : 4.0.5 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/notebook * License : BSD-3-clause Programming Lang: Python Description : Jupyter interactive notebook The Jupyter HTML notebook is a web-based notebook environment for interactive computing. Snark on #debian-python
