I have had to ask "why should we change from tool <foo> to <bar>" a few
times now for the project and some of the commit messages seem like they
could have already have answered all these questions beforehand.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
We also make sure that we recommend the installation of both the "regular"
dependencies and the "development" dependencies via `pip`.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
This is essentially a cherry-pick of a previous commit of issue #345. As I
am not going to merge that, I am including its message here:
This may (or may not) be a cosmetic thing, but, otherwise, the generate
`PKG-INFO` file gets the platform listed as unknown, and I clearly don't
want it to be that way.
This closes#345.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
Otherwise, the missing files would break installation of the generated
tarball.
I am pretty sure that there are better ways to do this and I welcome any
solution that is more elegant than this.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
Since py.test allows us to use regular `assert` instead of `assertEquals`,
use that instead, since it makes some of the code clearer to me, at least.
There is more of this kind of change to come, once I get more into our
testing suite.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
From @FedericoCeratto pull request:
----
Add Tox support for unit/functional testing. It help testing different versions of Python.
fabfile.py already contains a target to run Tox.
The result.xml files can be parsed with https://github.com/FedericoCeratto/tox-pytest-summary
----
Thanks @FedericoCeratto for the contribution.
Python 3.2 has not been present in our list of tested environments anyway.
I would like to put it back, but only after I figure out how to ignore
failures with it (and we will most likely have failures with Python 3.2, due
to the str/unicode syntax changes).
I give up with this yaml syntax that I don't know how it is supposed to be.
Let's get back to being conservative and ignoring the presence of Python
3.5.
I don't quite get what the supposed syntax for this should be, but it seems
that travis considers only the first 2 entries when allowing failures.
While we are at it, we also remove 2.6 from the allowed failures, as that's
really a version that we want to support.
Apart from the syntax to ignore the failures (not really sure if that's
correct), I hope that this allows us to claim that we work with Python 3.5
at the moment (as that's the version that is being developed right now).
I based all these guesses of mine on:
https://github.com/travis-ci/travis-build/pull/404
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
I'm not really sure if we should declare compatibility with Python 3.2.
While we also test for pypy (via Travis CI), I am not really sure how to
specify that in the file (I still have to do some reading).
Also, I don't really expect any problems with the use of Python 3.5, but
since it is not (yet) tested with travis, I'm not yet putting it explicitly
here.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
This is still not really satisfactory, as it seems that we have a limitation
in the number of authors (or it seems that we should use an ad-hoc format)
for specifying who the authors are, according to various sources, including:
https://docs.python.org/2/distutils/setupscript.html#additional-meta-data
For that reason, I refrained from telling that I am an (the?) author of this
program, as John should be equally credited here, if not more. I only
listed myself as the maintainer of the program.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
After a considerable amount of RTFM, I try to summarize here what I
discovered, namely, that the problem is actually a conjunction of many
things:
* Python 2.6 and 2.7.x (with x <= 8) don't define the constants
`ssl.PROTOCOL_TLSv1_1` and `ssl.PROTOCOL_TLSv1_2`. [They were introduced
with Python 2.7.9][0]
* Having TLS v1.1 and TLS v1.2 seem to only be available with sufficiently
new versions of OpenSSL. Again, this is reading from [the Python docs][0].
* urllib3, as a result, doesn't seem to support explicitly specifying which
which version of TLS to use, as far as I can see it (both by reading the
reading the code and by reading
https://github.com/shazow/urllib3/issues/487#issuecomment-59382798).
[0]: https://docs.python.org/2/library/ssl.html?highlight=ssl#ssl.PROTOCOL_TLSv1
Therefore, I guess that the best that we can do so far is to only request
`ssl.PROTOCOL_TLSv1` to be used. While it seems that TLS v1.0 has issues, I
hope that the packages we depend on manage to find a way to negotiate higher
versions of TLS, so that we can change that accordingly in the future.
A not so good alternative to that would be to decide dynamically (and
monkeypatch) urllib3 to see which TLS protocols we have and what we can try
to convice it to be used.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
