possible problem with virtualenv

TadLeonard commented 9 years ago

I'm using py.test for my project. It works nicely from within a virtualenv.

(env) (precise)tad@localhost:/share/husl-numpy$ which python
/home/tad/Downloads/share/husl-numpy/env/bin/python
(env) (precise)tad@localhost:/share/husl-numpy$ which py.test
/home/tad/Downloads/share/husl-numpy/env/bin/py.test
(env) (precise)tad@localhost:/share/husl-numpy$ python -c "import numpy; print(numpy.__version__)"
1.9.2

Note that numpy is importable. Let's run the tests.

(env) (precise)tad@localhost:/share/husl-numpy$ py.test test.py 
========================================================================= test session starts ==========================================================================
platform linux -- Python 3.4.3 -- py-1.4.30 -- pytest-2.7.2
rootdir: /home/tad/Downloads/share/husl-numpy, inifile: 
collected 33 items 

test.py .................................

====================================================================== 33 passed in 0.93 seconds =======================================================================

Yay! It works. Now, here's where I've put green:

(env) (precise)tad@localhost:/share/husl-numpy$ which green
/home/tad/Downloads/share/husl-numpy/env/bin/green

Let's run the tests with green:

(env) (precise)tad@localhost:/share/husl-numpy$ green test.py 
Traceback (most recent call last):
  File "/usr/local/bin/green", line 9, in <module>
    load_entry_point('green==2.0.0', 'console_scripts', 'green')()
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/cmdline.py", line 79, in main
    result = run(test_suite, stream, args) # pragma: no cover
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/runner.py", line 92, in run
    targets = [(target, manager.Queue()) for target in toParallelTargets(suite, args.targets)]
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 57, in toParallelTargets
    proto_test_list = toProtoTestList(suite)
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 42, in toProtoTestList
    toProtoTestList(i, test_list, doing_completions)
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 42, in toProtoTestList
    toProtoTestList(i, test_list, doing_completions)
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 36, in toProtoTestList
    getattr(suite, exception_method)()
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 398, in testFailure
    raise ImportError(message)
ImportError: Failed to import test:
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 390, in loadTarget
    tests = loader.loadTestsFromName(dotted_path)
  File "/usr/local/lib/python3.4/unittest/loader.py", line 105, in loadTestsFromName
    module = __import__('.'.join(parts_copy))
  File "/home/tad/Downloads/share/husl-numpy/test.py", line 2, in <module>
    import numpy as np
ImportError: No module named 'numpy'

What might I be doing wrong? Thanks.

CleanCut commented 9 years ago

Well, I'm not sure how it happened, but despite your which green output, your traceback output shows that you are running /usr/local/bin/green which is using /usr/local/lib/python3.4/site-packages which doesn't have numpy installed. You just need to get the right green called.

One way is you could try calling the virtualenv copy of green directly:

/home/tad/Downloads/share/husl-numpy/env/bin/green test.py

TadLeonard commented 9 years ago

Thanks for the help. Yes, running env/bin/green directly works. I still don't understand why nose and py.test behave differently in my setup.

If you don't mind me asking an unrelated question here... how do I get green to run py.test/nose style tests (i.e. simple functions starting with "test_' that pass/fail via assert statements)?

CleanCut commented 9 years ago

@TadLeonard Green's test discovery is currently based on the built-in unittest implementation, which only looks at unittest.TestCase subclasses. @msoedov was saying just yesterday in the Gitter channel that he was going to look into adding that type of support to discovery.

If we do add support, I expect that you will most likely need to enable it explicitly via some option such as --extra-discovery. Those of us who are used to using unittest actually have non-unit-test-related functions that start with test_...

CleanCut / green

possible problem with virtualenv #73