Hi, how are you? Awesome-fantastically-great? Good. Sorry for the break but it's been busy. I know, I know, it always is, but sometimes it's really busy. Anyway.
If you follow our Twitter account (no pressure, but you really should) then you could see some action in the last couple of days. Nothing major, but we did a little bit of a um... winter cleaning for of our open source projects:
Some minor cleaning up here and there, adding some new tricks that I learned in the last couple of months. But probably most importantly, updating our Tox configuration to test the code against Python 2.7, 3.4, 3.5 and recently released 3.6 version, adding code style testing via flake8 and finishing it all of via integration with Coveralls. Oh, and did I mention that all of this happens automatically after each push and on each pull request with the help of the awesome Travis CI. Also - badges. Did you hear that? That was the sound of me arriving in geek heaven. I like it here.
And with all that, I though it's a good excuse to do a rundown of our open source stack.
Well, duh, but what I mean by that are Python versions. I'm a big Python 3 supporter and was lucky enough to start with Python around the time when Python 3 had the popular libraries support and starting a new project in it was a no-brainer. I've heard that it wasn't always the case : -)
So originally we supported Python 2.7 only on the most popular
icon-font-to-png and decided to release other libraries
as Python 3 only for a couple of reasons. I still believe it isn't necessarily
a bad choice, but if a couple hours of work, extra UTF-8 shebang, couple of
imports from the future and weird looking imports from
six is all it
needs to run on both Python 2.7 and 3.x then sure, why not. Also -
We decided to support Python 2.7, 3.4, 3.5 and 3.6 for the foreseeable future.
We debated this internally for a bit and ended up on pytest. To be honest, more because the lack of any preference for the rest of the guys and my personal preference of it. By default, my favorite kind of winning : -)
Well, I don't have a really good answer for that, but I'm sure that someone on
the internet has. For me it was the thing I started with and just never felt
the need to change. So far so good basically. It works as expected with a
couple of lovely features that I was surprised not to see in other frameworks
when I occasionally work with them. And I will never understand the need for
Yeah, I don't know if the title is entirely correct because I'm sure that
pytest is also a test runner. Sue me - I needed a paragraph to put Tox
While there are a couple of big and popular Python test frameworks, I think I always saw them being 'plugged into' Tox, which - if you don't know - automates your testing and allows you to run your tests in multiple separate virtualenvs. Practically a must have when you want to support multiple Python versions and make sure that tests pass on each of them.
Code style guide
We all know tests are important. There's a bit more of divisiveness for code coverage as a code quality metric, but I think it's absolutely fine if you don't go mental about it and strive for 100% everywhere. At the very least, it can show you which edge cases (or even whole classes and/or functions ; ) you forgot about.
Again, I belive Coverage.py is the clear crowd favourite.
There are more options for showing the data online though. I played with Codecov for a bit but ultimately decided on Coveralls. I'm still new to it and had some problems setting it up, but everything else has been good so far.
Continuous Integration service
This category is actually quite stacked up, with most of the services allowing unlimited number of open source repos. We have Circle CI, Scrutinizer, Codeship, self hosted Jenkins, GitLab CI and many, many more. Lastly, we have Travis CI which is what we're using. Again, people much smarter than me already did all the comparisons and I'm sure all of these would work perfectly well for our small needs.
So many choices, so many possibilities. Like I said, geek heaven.