Using setup.py for tests about pingo-py

[danilobellini]

Yes, but that's still a hack. The develop command "installs" the package by creating a symlink to the development directory, which makes it impossible to call the tests without explicitly creating a virtual environment or calling develop with "sudo". That's also probably why the install command is broken for now (it isn't installing any subpackage).

Anyhow, for testing, one shouldn't need to install anything. Calling python setup.py test should be enough.

[ramalho]

As I told you before, Danilo, we need help with organizing the package and
the tests.

But I really do not see this happening without a few hours of sprinting
together in person, with you present, because it will take too long to fix
the issues via these discussions, and a remote pull request with wide
ranging structural changes is too hard to handle.

When do you think we can meet to work together on Pingo at Garoa?

On Wed, May 7, 2014 at 12:52 AM, Danilo de Jesus da Silva Bellini <
[email protected]> wrote:

Yes, but that's still a hack. The develop command "installs" the package
by creating a symlink to the development directory, which makes it
impossible to call the tests without explicitly creating a virtual
environment or calling develop with "sudo". That's also probably why the
install command is broken for now (it isn't installing any subpackage).

Anyhow, for testing, one shouldn't need to install anything. Calling python
setup.py test should be enough.

—
Reply to this email directly or view it on GitHubhttps://github.com/garoa/pingo/issues/23#issuecomment-42387116
.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[valdergallo]

I updated all tests to run with py.test
But I don't have any board :(
Can you check my commits, pls :D

[Vido]

Hi valdergallo,

First, thank you for contributing with Pingo.
Perhaps you would like to join your mailing list too: [email protected]

Second, great work. But...
I've cloned your fork, and the results of some tests were:

XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_jumpwire
  pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_led
  pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_list_pins
  pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooExceptions::test_disabled_pin
  pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooExceptions::test_wrong_pin_mode_in
  pingo.rpi requires RPi.GPIO installed

Udoo's tests should not fail because of RPi.GPIO's absence.
They should have no requirements (besides python and pingo).

EDIT:
If your run them on a x86 machine instead of a Udoo, the tests should fail
because of the lack the /sys/class/gpio/ files. Not because RPi.GPIO.

[ramalho]

Vido, these failures may have to do with a packaging mistake that Danilo
has been talking about previously. Monday night at Garoa I had a similar
problem while trying to do a Coding Dojo on a notebook running Ubuntu. I
did a checkout from master and installed system wide (I was in a hurry, 20
people watching) and when I typed import pingo at the Python 2.7 console I
got an exception about failing to import the rpi package. Not exactly the
same problem, but may be related. We need to look into this but I have no
time today.

On Wed, May 14, 2014 at 10:41 AM, Lucas Vido [email protected]:

Hi valdergallo,

First, thank you for contributing with Pingo.
Perhaps you would like to join your mailing list too:
[email protected]

Second, great work. But...
I've cloned your fork, and the results of some tests were:

XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_jumpwire
pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_led
pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooBasics::test_list_pins
pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooExceptions::test_disabled_pin
pingo.rpi requires RPi.GPIO installed
XFAIL pingo/udoo/tests/test_udoo.py::UdooExceptions::test_wrong_pin_mode_in
pingo.rpi requires RPi.GPIO installed

Udoo's tests should not fail because of RPi.GPIO's absence.
They should have no requirements (besides python and pingo).

—
Reply to this email directly or view it on GitHubhttps://github.com/garoa/pingo/issues/23#issuecomment-43081172
.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[Vido]

Ramalho, you are right.

python setup.py develop -> tests runs ok.
python setup.py install -> ImportError: No module named rpi

[ramalho]

One solution to this problem is to revert back to the simpler layout of
having the driver modules in the same directory as board.py. We could then
move the driver-specific examples and tests to some other place. According
to Danilo, making the current sub-package structure work is harder and not
worthwhile. this has been one of his biggest complaints.

On Wed, May 14, 2014 at 11:04 AM, Lucas Vido [email protected]:

Ramalho, you are right.

python setup.py develop -> tests runs ok.
python setup.py install -> ImportError: No module named rpi

—
Reply to this email directly or view it on GitHubhttps://github.com/garoa/pingo/issues/23#issuecomment-43084055
.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[valdergallo]

@Vido Hi Vido, tnx :D

Did you test python setup.py install on my fork ?
Because I had resolved this problem on commit d7667eb

-metadata["packages"] = [metadata["name"]]
 +metadata["packages"] = find_packages(where='.', exclude=['*test*'])

@Vido About the xfail:
So, ok no problems. I will change.

#pullrequest
I will fix all tests and make one pull request tomorrow. My friend will lend me one Arduino 👯

[danilobellini]

Udoo's tests should not fail because of RPi.GPIO's absence.

@Vido, an xfail isn't a "fail", but a special kind of skip. It means "expected to fail", a "skip" used for something still incomplete that should be implemented in the future, or perhaps an incomplete testing environment. Probably an explicit skip there would make more sense there than an xfail, as the RPi package would never be imported on Udoo. Anyhow, that's not failing: py.test still returns 0 - no error/failure - when there are only xfails and skips, and that's an information used by tox, Travis CI, etc..

@valdergallo, you're right, your branch solves both this issue and the issues regarding the incomplete install due to a subpackage nesting. As @ramalho said, I prefer a "flat is better than nested" approach for package structure as I see no reason for using several "onefiler" directories, but probably that wouldn't change what you did except perhaps the newer __init__.py for each test directory, but renaming files to test_*.py was already a step in that "flatten" direction. Anyhow, regarding your branch, if you can get rid from that genscript blob, the resulting setup.py would be simpler. =)