Pythonity Blog Pythonity Blog

Pythonity's Open Source Stack

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.

Python

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 - universal wheels.

We decided to support Python 2.7, 3.4, 3.5 and 3.6 for the foreseeable future.

Project hosting

Absolutely nothing against GitLab (we self host it for our company projects!) and BitBucket but GitHub is where everything's (including Python in a little bit) at. Sorry, not sorry.

Test framework

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 : -)

But why pytest though?

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 self.assertItIsMoreThenFourButLessThanTen stuff.

Test runner

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 in.

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

PEP 8 guys, use it. And if you're using it, then why not test your code against it with flake8 plugged into you Tox configuration? Only good stuff can happen.

Code coverage

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.

Comments