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 tes
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 MAN
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 g
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_
[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-ar
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.
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
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 Pytho
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_
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
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.
>>
>>
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 he
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
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 un
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 mi
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 though
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
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 Pyth
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 bas
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
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
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 Pytho
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?
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_
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
25 matches
Mail list logo
