setup.py rewritten to pbr, tests run by tox

[vlcinsky]

modified:   .gitignore
deleted:    AUTHORS
deleted:    CHANGELOG
deleted:    MANIFEST.in
new file:   requirements-py26.txt
new file:   requirements.txt
new file:   setup.cfg
modified:   setup.py
renamed:    tests.py -> tests/test_it.py
new file:   tox.ini

[vlcinsky]

Resolves issue #39 (tox), #38 (pbr) and partially also #40 (pytest) and #37 (version).

[vlcinsky]

Now it resolves the issue #37

[vlcinsky]

One thing, which is bothering a bit with using pbr is automated generation of AUTHORS and ChangeLog.

pros and cons of using pbr

pros:

• simplicity and automation
• AUTHORS are automatically collected
• ChangeLog is automatically written from commit messages and grouped per tagged version

cons:

• more strict rules to write commit message carefully, one failing message can harm nice changelog (but this does not seem to be fatal)
• no option to customize the ChangeLog
• no option to customize Authors
• no ChangeLog and AUTHORS in the codebase (if we consider commit messages being part of codebase, then this complain does not hold true)

pbr realated options we have

To me there seem to be following options:

(opt 1) Be happy with automated results

Just accept what is generated and do not bother with unimportant details.

(opt 2) Manually created AUTHORS.rst and ChangeLog.rst + pbr generated ones

pbr creates AUTHORS and ChangeLog (mind the missing .rst extension)

If we keep manually created AUTHORS.rst and ChangeLog.rst, they would not conflict with pbr created files and would allow any custom content.

With pbr created files (being present only in generated installation file) it would be easy to collect changes for updating the manually maintained files.

(opt 3) Use customized pbr, e.g. packit

There is package called packit

It allows some customization and we could control the results from here

(opt 4) Skip using pbr style packaging

Skipping pbr style of package creation is of course an option.

Conclusions

I would prefer the option 1 or 2.
Option 3 adds a bit of complexity, which does not seem to be necessary.

Option 4 I do not like at all as we get back to rather complex setup.py.

[vlcinsky]

Updated to merge without conflicts with current master.
As we have in master a problem:

Traceback (most recent call last):
  File "/opt/python/3.4.2/lib/python3.4/threading.py", line 921, in _bootstrap_inner
    self.run()
  File "/opt/python/3.4.2/lib/python3.4/threading.py", line 869, in run
    self._target(*self._args, **self._kwargs)
  File "/home/travis/build/jorgebastida/awslogs/awslogs/core.py", line 129, in consumer
    print(' '.join(output))
  File "/home/travis/build/jorgebastida/awslogs/.tox/py34/lib/python3.4/codecs.py", line 369, in write
    self.stream.write(data)
TypeError: string argument expected, got 'bytes

my current PR is failing in the same way for python 3.*

[jorgebastida]

Hello @vlcinsky (first of all, sorry for the long delay)

I've read quite a lot about pbr... and I'm not convinced. I might change my opinion in the future, but right now it is a bit too much magic to me. I understand setup.py files are not easy to read... but I have the feeling the usage we would be doing of pbr would basically mean we'll write the setup.py file in a different (ini) syntax instead of python... and that would be (yet another) thing to learn and maintain.

In the other hand, I think the tox/travis changes were brilliant! I've create a new PR only including them and a few more changes. See #69

Hope you understand my view.

[vlcinsky]

@jorgebastida Thanks a lot for merging things in. I understand your decision to not accept pbr. The fact, tox and other "waiting" stuff is not part of master branch will simplify my further work (on click, and possibly some py.test related stuff).