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.
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 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: 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
[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 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
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 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 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 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 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: > > 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 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: 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 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?
Re: Python < 3.5 tests
On 8 October 2015 at 18:57, Brian May wrote: > > > On Thu, 8 Oct 2015 at 08:12 Brian May > wrote: >> >>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build; >>python3.5 -m unittest discover -v >>ajax_select (unittest.loader._FailedTest) ... ERROR >> > > On second thoughts, wonder what tests it is running. I can't see anything > that looks like a test in the package... setup.py has nothing either. > > Cut and paste doesn't work properly with this stupid Google inbox webclient > - otherwise I would add a list of the source files here, however this is the > django-ajax-selects package in Debian. > > Only thing I can think of is maybe it is picking up the Django tests, which > are meaningless here. Presumably https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests would be the intent? The tarball on PyPI is missing it - so I think its a broken MANIFEST.in - it hasn't been updated to include the tests. So the error thats being reported is that ajax_select can't be imported - which means that ajax_select/__init__.py can't be imported. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 08:12 Brian May wrote: >I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build; >python3.5 -m unittest discover -v >ajax_select (unittest.loader._FailedTest) ... ERROR > > On second thoughts, wonder what tests it is running. I can't see anything that looks like a test in the package... setup.py has nothing either. Cut and paste doesn't work properly with this stupid Google inbox webclient - otherwise I would add a list of the source files here, however this is the django-ajax-selects package in Debian. Only thing I can think of is maybe it is picking up the Django tests, which are meaningless here.
Re: Python < 3.5 tests
On 8 October 2015 at 12:05, Ben Finney wrote: > Robert Collins writes: > >> On 8 October 2015 at 11:47, Ben Finney wrote: >> > If you have a code base that is intended to run unchanged on Python >> > 2 and Python 3, and that code base imports ‘unittest2’, you need >> > both the Python 2 and Python 3 version of that package. >> > >> > If your code base targets only Python 3, it should not be using >> > ‘unittest2’ at all. >> >> Thats false. unittest2 is a rolling backport. > > I'm not sure how that disagrees with what I wrote. > > Are you saying ‘unittest2’ is useful on Python 3.3 (for example) because > it has improvements from later Python 3 standard library ‘unittest’? Yes, exactly. unittest2 is useful and relevant on Python 3.2/3.3/3.4 today. Once we get some fixes into 3.6, it will be useful and relevant for 3.5 users. > Or something else? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
Robert Collins writes: > On 8 October 2015 at 11:47, Ben Finney wrote: > > If you have a code base that is intended to run unchanged on Python > > 2 and Python 3, and that code base imports ‘unittest2’, you need > > both the Python 2 and Python 3 version of that package. > > > > If your code base targets only Python 3, it should not be using > > ‘unittest2’ at all. > > Thats false. unittest2 is a rolling backport. I'm not sure how that disagrees with what I wrote. Are you saying ‘unittest2’ is useful on Python 3.3 (for example) because it has improvements from later Python 3 standard library ‘unittest’? Or something else? > A true statement would be 'if your codebase will only ever run on the > latest release of Python then unittest2 offers no value' for it. Agreed. -- \ “We must respect the other fellow's religion, but only in the | `\ sense and to the extent that we respect his theory that his | _o__) wife is beautiful and his children smart.” —Henry L. Mencken | Ben Finney
Re: Python < 3.5 tests
On 8 October 2015 at 11:26, Brian May wrote: > On Thu, 8 Oct 2015 at 08:18 Robert Collins > wrote: >> >> Probably the discover improvements in 3.5 try using python -m >> unittest2.discover > > > Just trying that now. > > I see that there is a python3-unittest2 package - should I be using that one > or the unittest built in Python 3.5? let me check I understood the symptoms: python3.5 - works python2.x fails python3.4 fails So for that - use unittest2 consistently everywhere IMO. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
On 8 October 2015 at 11:47, Ben Finney wrote: > Brian May writes: > >> I see that there is a python3-unittest2 package - should I be using that >> one or the unittest built in Python 3.5? > > If you have a code base that is intended to run unchanged on Python 2 > and Python 3, and that code base imports ‘unittest2’, you need both the > Python 2 and Python 3 version of that package. > > If your code base targets only Python 3, it should not be using > ‘unittest2’ at all. Thats false. unittest2 is a rolling backport. A true statement would be 'if your codebase will only ever run on the latest release of Python then unittest2 offers no value' for it. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
Re: Python < 3.5 tests
Brian May writes: > I see that there is a python3-unittest2 package - should I be using that > one or the unittest built in Python 3.5? If you have a code base that is intended to run unchanged on Python 2 and Python 3, and that code base imports ‘unittest2’, you need both the Python 2 and Python 3 version of that package. If your code base targets only Python 3, it should not be using ‘unittest2’ at all. -- \ “He may look like an idiot and talk like an idiot but don't let | `\ that fool you. He really is an idiot.” —Groucho Marx | _o__) | Ben Finney
Re: Python < 3.5 tests
On Thu, 8 Oct 2015 at 08:18 Robert Collins wrote: > Probably the discover improvements in 3.5 try using python -m > unittest2.discover > Just trying that now. I see that there is a python3-unittest2 package - should I be using that one or the unittest built in Python 3.5?
Re: Python < 3.5 tests
Probably the discover improvements in 3.5 try using python -m unittest2.discover On 8 Oct 2015 10:12, "Brian May" wrote: > Hello, > > When debugging #801208, I noticed the following output: > >dh_auto_test -O--buildsystem=pybuild >I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build; >python2.7 -m unittest discover -v > >-- >Ran 0 tests in 0.000s > >OK >I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build; >python3.4 -m unittest discover -v > >-- >Ran 0 tests in 0.000s > >OK >I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build; >python3.5 -m unittest discover -v >ajax_select (unittest.loader._FailedTest) ... ERROR > > 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? > * Why is Python 3.4 still relevant? Hasn't 3.5 replaced 3.4? Why is it > being tested by pybuild? > > Regards > >
Python < 3.5 tests
Hello, When debugging #801208, I noticed the following output: dh_auto_test -O--buildsystem=pybuild I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover -v -- Ran 0 tests in 0.000s OK I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build; python3.4 -m unittest discover -v -- Ran 0 tests in 0.000s OK I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest discover -v ajax_select (unittest.loader._FailedTest) ... ERROR 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? * Why is Python 3.4 still relevant? Hasn't 3.5 replaced 3.4? Why is it being tested by pybuild? Regards
