[gentoo-python] recent trend of django-foo tests

[gentoo-python] recent trend of django-foo tests

[IAN DELANEY]

Am generally reluctant to enter things here, however this issues
appears apt.  Recent versions of django-xxx packages' test suites  have
made a habit of falling over, which is no surprise in itself, but they
have a new cause.  They all expect to find a setting to SECRET_KEY
which is set in djang.conf.global_settings.

For  while I thought

"${PYTHON}" -c "from django.conf import \
global_settings;global_settings.SECRET_KEY='green'" ${test} 

did the trick but it seems that the ${test} after the import with -c "
" is discarded somehow and never actually run with the attempt to set 
SECRET_KEY='green'.  The output looks as if it was an effective run but
it's not the case.

How this came about, who knows.  The backtrace tells it's expecting a
hard coded entry in the installed global_settings.py.  django has some
other django specific mechanisms for running test suites and setting
settings. Anyone know at least one?  How about patching django itself
to include the setting? (That one I expect goes down like a lead
balloon.)


 
kind regards

Ian Delaney

Re: [gentoo-python] recent trend of django-foo tests

[Nikolaj Sjujskij]

Den 2013-05-20 13:05:33 skrev IAN DELANEY <della5@iinet.com.au>:

>
> Am generally reluctant to enter things here, however this issues
> appears apt.  Recent versions of django-xxx packages' test suites  have
> made a habit of falling over, which is no surprise in itself, but they
> have a new cause.  They all expect to find a setting to SECRET_KEY
> which is set in djang.conf.global_settings.
>
> For  while I thought
>
> "${PYTHON}" -c "from django.conf import \
> global_settings;global_settings.SECRET_KEY='green'" ${test}
>
> did the trick but it seems that the ${test} after the import with -c "
> " is discarded somehow and never actually run with the attempt to set
> SECRET_KEY='green'.
  % python -h
    ...
-c cmd : program passed in as string (_terminates option list_)

So ${test} seems to be ignored or misinterpreted.


You could try creating ./global_settings.py in :

     from django.conf import global_settings
     global_settings.SECRET_KEY='green'

     print(global_settings)   # testing purposes!

Now:
  % python -c 'import global_settings'
<module 'django.conf.global_settings' from  
'/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>

Re: [gentoo-python] recent trend of django-foo tests

[IAN DELANEY]

On Mon, 20 May 2013 13:18:53 +0400
"Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:

> Den 2013-05-20 13:05:33 skrev IAN DELANEY <della5@iinet.com.au>:
> 
>     ...
> -c cmd : program passed in as string (_terminates option list_)
> 
> So ${test} seems to be ignored or misinterpreted.
> 
> 
> You could try creating ./global_settings.py in :
> 
>      from django.conf import global_settings
>      global_settings.SECRET_KEY='green'
> 
>      print(global_settings)   # testing purposes!
> 
> Now:
>   % python -c 'import global_settings'
> <module 'django.conf.global_settings' from  
> '/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>

Ja, tack tack for att forsoka, med nej. (Please add the grammatical
nice-ities to the vowel o).  I got a fix from #django on the second
attempt. I was close on the first attempt, so for the benefit of all, 

first export SECRET_KEY='green', followed by

-    "from django.conf import \
  global_settings;global_settings.SECRET_KEY='green'" ${test}
+    "from django.conf import \
  global_settings;global_settings.SECRET_KEY='$SECRET_KEY'" ${test}

and presto.

 * python2_7: running distutils-r1_run_phase python_test
 * test test_compiler.py passed under python2.7
 * test test_compressor.py passed under python2.7

another bug bites the dust.

-- 
kind regards

Ian Delaney

Re: [gentoo-python] recent trend of django-foo tests

[Nikolaj Sjujskij]

Den 2013-05-20 20:37:53 skrev IAN DELANEY <della5@iinet.com.au>:

> On Mon, 20 May 2013 13:18:53 +0400
> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>
>> Den 2013-05-20 13:05:33 skrev IAN DELANEY <della5@iinet.com.au>:
>>
>>     ...
>> -c cmd : program passed in as string (_terminates option list_)
>>
>> So ${test} seems to be ignored or misinterpreted.
>>
>>
>> You could try creating ./global_settings.py in :
>>
>>      from django.conf import global_settings
>>      global_settings.SECRET_KEY='green'
>>
>>      print(global_settings)   # testing purposes!
>>
>> Now:
>>   % python -c 'import global_settings'
>> <module 'django.conf.global_settings' from
>> '/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>
>
> Ja, tack tack for att forsoka, med nej. (Please add the grammatical
> nice-ities to the vowel o).
  I've got bad news for you: actually my native language is Russian :)

> I got a fix from #django on the second
> attempt. I was close on the first attempt, so for the benefit of all,
>
> first export SECRET_KEY='green', followed by
>
> -    "from django.conf import \
>   global_settings;global_settings.SECRET_KEY='green'" ${test}
> +    "from django.conf import \
>   global_settings;global_settings.SECRET_KEY='$SECRET_KEY'" ${test}
  I positively fail to see how that change could fix anything.

  % python global_settings.py
<module 'django.conf.global_settings' from  
'/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>

  % python -c 'import sys; print sys.platform' global_settings.py
linux2

> and presto.
>
>  * python2_7: running distutils-r1_run_phase python_test
>  * test test_compiler.py passed under python2.7
>  * test test_compressor.py passed under python2.7
> another bug bites the dust.
  Well, if that somehow had worked, it's all right, I guess.

Re: [gentoo-python] recent trend of django-foo tests

[Nikolaj Sjujskij]

Den 2013-05-21 21:35:24 skrev IAN DELANEY <della5@iinet.com.au>:

> On Tue, 21 May 2013 12:56:50 +0400
> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>
>> Den 2013-05-20 20:37:53 skrev IAN DELANEY <della5@iinet.com.au>:
>>
>>> Ja, tack tack for att forsoka, med nej. (Please add the grammatical
>>> nice-ities to the vowel o).
>>   I've got bad news for you: actually my native language is Russian :)
>>
> Oh dear, more bad news, this isn't a good week.  Header read;
> "Den 2013-05-20 20:37:53 skrev"
> Den is 'the', skrev is wrote in swedish.
  Yep, my email client speaks Swedish :)

>>> I got a fix from #django on the second
>>> attempt. I was close on the first attempt, so for the benefit of
>>> all,
>>>
>>> first export SECRET_KEY='green', followed by
>>>
>>> -    "from django.conf import \
>>>   global_settings;global_settings.SECRET_KEY='green'" ${test}
>>> +    "from django.conf import \
>>>   global_settings;global_settings.SECRET_KEY='$SECRET_KEY'" ${test}
> well I'm open to an explanation too, but in brief, he said set the key
> in bash, then on a second attempt on re-reading my query more closely,
> he corrected it to the above.  An alternate was SECRET_KEY="green"
> python -c ..., that is pre-pending the setting of the secret key to the
> call to python, which should work if you try. I settled for the above.
  I mean, python should ignore (and it does for me) arguments after -c  
option, however you do that in bash:

  % python global_settings.py
<module 'django.conf.global_settings' from  
'/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>

  % python -c "print('$LANG')" global_settings.py
ru_RU.UTF-8

  I'm not sure you understand my code snippets correctly. I demonstrate how  
python ignores "global_settings.py" argument and doesn't run the script  
whose name was passed after `-c <python code>` option.

>>   I positively fail to see how that change could fix anything.
>>   % python global_settings.py
>> <module 'django.conf.global_settings' from
>> '/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>
>>
> I'm guessing here the manufactured global_settings.py could be used
> effectively, I'd have to go back and try some more to do so. But hey
> thx for the effort.
>>   % python -c 'import sys; print sys.platform' global_settings.py
>> linux2
>>
>>> and presto.
>>>
>>>  * python2_7: running distutils-r1_run_phase python_test
>>>  * test test_compiler.py passed under python2.7
>>>  * test test_compressor.py passed under python2.7
>>> another bug bites the dust.
>>   Well, if that somehow had worked, it's all right, I guess.
>>
> a good news snippet to offset the bad.  What can I say?
  I'm just pointing out that I for one can't understand what's happening  
there and why it seems to work while it shouldn't. Therefore it may break  
again unexpectedly, so just keep that in mind :)

Re: [gentoo-python] recent trend of django-foo tests

[IAN DELANEY]

On Tue, 21 May 2013 12:56:50 +0400
"Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:

> Den 2013-05-20 20:37:53 skrev IAN DELANEY <della5@iinet.com.au>:
> 
> > Ja, tack tack for att forsoka, med nej. (Please add the grammatical
> > nice-ities to the vowel o).
>   I've got bad news for you: actually my native language is Russian :)
> 
Oh dear, more bad news, this isn't a good week.  Header read;
"Den 2013-05-20 20:37:53 skrev"
Den is 'the', skrev is wrote in swedish. 

> > I got a fix from #django on the second
> > attempt. I was close on the first attempt, so for the benefit of
> > all,
> >
> > first export SECRET_KEY='green', followed by
> >
> > -    "from django.conf import \
> >   global_settings;global_settings.SECRET_KEY='green'" ${test}
> > +    "from django.conf import \
> >   global_settings;global_settings.SECRET_KEY='$SECRET_KEY'" ${test}

well I'm open to an explanation too, but in brief, he said set the key
in bash, then on a second attempt on re-reading my query more closely,
he corrected it to the above.  An alternate was SECRET_KEY="green"
python -c ..., that is pre-pending the setting of the secret key to the
call to python, which should work if you try. I settled for the above.

>   I positively fail to see how that change could fix anything.
> 
>   % python global_settings.py
> <module 'django.conf.global_settings' from  
> '/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>
> 
I'm guessing here the manufactured global_settings.py could be used
effectively, I'd have to go back and try some more to do so. But hey
thx for the effort.

>   % python -c 'import sys; print sys.platform' global_settings.py
> linux2
> 
> > and presto.
> >
> >  * python2_7: running distutils-r1_run_phase python_test
> >  * test test_compiler.py passed under python2.7
> >  * test test_compressor.py passed under python2.7
> > another bug bites the dust.
>   Well, if that somehow had worked, it's all right, I guess.
> 
a good news snippet to offset the bad.  What can I say?



-- 
kind regards

Ian Delaney

Re: [gentoo-python] recent trend of django-foo tests

[Mike Gilbert]

On Mon, May 20, 2013 at 1:36 PM, IAN DELANEY <della5@iinet.com.au> wrote:
> On Mon, 20 May 2013 13:18:53 +0400
> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>
>> Den 2013-05-20 13:05:33 skrev IAN DELANEY <della5@iinet.com.au>:
>>
>>     ...
>> -c cmd : program passed in as string (_terminates option list_)
>>
>> So ${test} seems to be ignored or misinterpreted.
>>
>>
>> You could try creating ./global_settings.py in :
>>
>>      from django.conf import global_settings
>>      global_settings.SECRET_KEY='green'
>>
>>      print(global_settings)   # testing purposes!
>>
>> Now:
>>   % python -c 'import global_settings'
>> <module 'django.conf.global_settings' from
>> '/usr/lib64/python2.7/site-packages/django/conf/global_settings.pyc'>
>
> Ja, tack tack for att forsoka, med nej. (Please add the grammatical
> nice-ities to the vowel o).  I got a fix from #django on the second
> attempt. I was close on the first attempt, so for the benefit of all,
>
> first export SECRET_KEY='green', followed by
>
> -    "from django.conf import \
>   global_settings;global_settings.SECRET_KEY='green'" ${test}
> +    "from django.conf import \
>   global_settings;global_settings.SECRET_KEY='$SECRET_KEY'" ${test}
>
> and presto.
>
>  * python2_7: running distutils-r1_run_phase python_test
>  * test test_compiler.py passed under python2.7
>  * test test_compressor.py passed under python2.7
>
> another bug bites the dust.
>

Ian:

You have NOT fixed a bug; rather you have masked one. As Nikolaj
indicates, python -c "code" foo.py does NOT run foo.py.

The change you have made causes the tests to be skipped entirely. A
message stating "tests passed" does not signify that anything was
actually run.

If you cannot figure this out, please remove python_test from any
ebuilds you have modified. At least that way we don't give the false
impression that the tests have actually passed.

Re: [gentoo-python] recent trend of django-foo tests

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 2059 bytes --]

2013-05-30 21:34 Mike Gilbert napisał(a):
> python -c "code" foo.py does NOT run foo.py.

$ cat my_script
#!/usr/bin/python

import sys
import unittest

class SomeTests(unittest.TestCase):
    def test_something(self):
        self.assertTrue(sys.something > 0)

if __name__ == "__main__":
    unittest.main(verbosity=2)
$ diff -u my_script my_module.py
$ python my_script
test_something (__main__.SomeTests) ... ERROR

======================================================================
ERROR: test_something (__main__.SomeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "my_script", line 8, in test_something
    self.assertTrue(sys.something > 0)
AttributeError: 'module' object has no attribute 'something'

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)
$ python -m my_module
test_something (__main__.SomeTests) ... ERROR

======================================================================
ERROR: test_something (__main__.SomeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./my_module.py", line 8, in test_something
    self.assertTrue(sys.something > 0)
AttributeError: 'module' object has no attribute 'something'

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)
$ python -c 'import runpy, sys; sys.something=1; runpy.run_path("my_script", run_name="__main__")'
test_something (__main__.SomeTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
$ python -c 'import runpy, sys; sys.something=1; runpy.run_module("my_module", run_name="__main__", alter_sys=True)'
test_something (__main__.SomeTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
$

:)

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]