Fix test_sdist not finding setup.py or sdist

[koobs]

Fix test_packaging:test_sdist which was failing with the following errors running py.test from the sdist root:

test/test_packaging.py:40:
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

popenargs = (['/usr/local/bin/python2.7', 'setup.py', 'sdist'],), kwargs = {'cwd': '..'}, process = <subprocess.Popen object at 0x8058db5d0>, output = '', unused_err = None, retcode = 2
cmd = ['/usr/local/bin/python2.7', 'setup.py', 'sdist']
<snip>
------- Captured stderr call ------------
/usr/local/bin/python2.7: can't open file 'setup.py': [Errno 2] No such file or directory

Subsequently, test_sdist failed finding the resulting sdist tarball, with the following error:

E           CalledProcessError: Command '['/usr/local/bin/python2.7', '-m', 'pip', 'install', '--target', '/tmp/tmptcRmwE', '--no-deps', '../dist/txaio-2.2.1.tar.gz']' returned non-zero exit stat
us 2

/usr/local/lib/python2.7/subprocess.py:573: CalledProcessError
----------------------------- Captured stderr call ---------------------------------------------------------------------------------------
Requirement '../dist/txaio-2.2.1.tar.gz' looks like a filename, but the file does not exist

This change fixes those issues accordingly:

• Fix test_packaging:test_sdist to work from the sdist root, as it cannot
  find setup.py due to cwd=../ being set, assuming the test is being run
  from the test/ directory.
• Fix validating the resulting sdist (.tar.gz), as the path includes a ../, which
  is incorrect (created in ./dist)

[oberstet]

Does not work: please see Travis. Note that this works flawlessly on FreeBSD - though not using FBSD packages, but plain vanilla Python built from source.

[koobs]

@oberstet The errors outlined in #53 (comment) are on a FreeBSD system running py.test or python -m pytest in the root dir

I'm not sure why the tox run fails, nor why the cwd=.. is needed for it.

Edit: It's possible related to the following line in tox.ini:

changedir=test

Which ought not be needed

[oberstet]

I don't know, and as said, I don't use Python system packages on FreeBSD. However, the patch breaks all of our test environments: https://travis-ci.org/crossbario/txaio/builds/104428299

[meejah]

I can't remember why tox needed it, but all the builders are sad now. Maybe I can setup tox + pytest so that this test only runs on the builders -- and it's not really a great test anyway :/

[meejah]

(I added the test because there was a txaio release that missed something from the manifest)

[koobs]

@meejah The best-practice method is to:

1. Have setup.py test hooked up (test_suite) (See pytest: Good integration practices)
2. Have tests_requires declared (so that they're installed when test is run)
3. Have tox run the test command

This way the development testing and downstream user/consumer QA testing use-cases are covered.

[meejah]

Thanks for the "setup.py test" hookup link. Your point 3 do you mean, use "python setup.py test" to run the tests (e.g. instead of invoking py.test)?

The real issue with the packaging test is finding the root of the source tree so that python setup.py sdist can be invoked properly (and the resulting tarball found)...but perhaps what you mean is that the test is redundant if the other changes are made?

[koobs]

@meejah Yep re point (3). one could have tox do its own different invocation (directly execute py.test or something else), but there ought to be no reason not to leverage/use it.

While the test for packaging doesn't appear to be valuable from a testing point of view, since it is release process specific, there is obvious relevance and value from a CI and test producing release artifacts for development purposes point of view.

Having said that, with the changes in this PR, all tests (including the packaging tests) do PASS, since the tests are invoked relative the the sdist root (and not from within test/)

That appears to point to a CI (Tox and/or Travis) environment or configuration issue, not a test issue. Resolving this may just be a matter of the packaging tests being aware of, and not being coupled to which location (cwd) they're being invoked from

[koobs]

I'll ping you on IRC to discuss further, though it's a little disappointed this PR was closed so quickly

[meejah]

Okay. I basically always run the tests with tox, which does work fine (including the packaging test). The only thing that doesn't work locally for me is doing py.test test/ from the root.