Moving To a New Software Ecosystem: The transition from Ruby to Python
For the past five years most of my software development experience has been with the Ruby on Rails framework, but recently I made the switch to the world of Python and the Pyramid web framework. For me, learning Python made sense because of Python’s popularity in both the professional and academic worlds. With the explosion of the data science field, Python has become the go-to language for many companies specializing in data science-based technology. Python’s math and science libraries can be used by both data scientists and software engineers for everything from data analysis to product and algorithm development. Overall, the past few months have been filled with everything from sheer confusion to pure bliss (in the form of lots of “a-ha” moments). Looking back, this transition was not as disruptive as I initially expected. Instead, this journey has been a fantastic opportunity not only to learn about a new programming ecosystem, but also to solidify my understanding of the programming ecosystem in which I’ve spent the last few years.
Where do I start?
This was the first question I found myself asking when I began this transition. I wasn’t sure if I should pick up an “introduction to Python” book, or if I should try online coding challenges. In reality it turned out to be a combination of both of these things. I started out with a book, Programming Python: 4th Edition by Mark Lutz. After a couple of chapters and a few hands-on tutorials, I loaded up an online code academy and focused on completing some challenges. With that foundation, I was able to hit the ground running when I started working with Pixability’s back-end platform, but before I could start developing, I had to get some of the Pixability micro-services running locally. Right off the bat, I noticed many similarities between the Ruby and Python worlds.
How do I avoid Version nightmares?
These ecosystems each have tools that specialize in the management of multiple versions of a language, with communities for both languages offering a wide variety of solutions for handling this challenge — each with their own unique way of “doing things.”
Two very popular version management solutions available for Ruby are RVM (the Ruby Version Manager) and rbenv. Although these tools have their differences, both tools provide an easy way for users to easily switch among multiple versions of Ruby.
Similarly, the Python community also offers plenty of tools for managing multiple versions of Python. Two that I found particularly helpful are Virtualenv and pyenv. Virtualenv is a Python-based tool that allows a user to create an isolated Python environment. pyenv, on the other hand, is a C-based bash tool that is actually a fork of the rbenv project. pyenv focuses on the management and installation of multiple versions of Python.
Because of my familiarity with RVM and rbenv, I chose to use the pyenv tool in combination with the pyenv-virtualenv add on. The pyenv-virtualenv tool provides added functionality and convenience for the creation of virtual Python environments using pyenv-based Python installations. Personally, I found the transition from RVM and rbenv to pyenv seamless. The commands for installing, removing, and setting particular versions of Python functioned almost identically to both Ruby tools. From a development perspective, these tools all provide a way to accomplish the following:
- �Manage and install multiple versions of a language
- Manage and install multiple versions of third party packages on a language version basis
- Change which version of a language is being used
- Run multiple versions of the same language concurrently
- Integrate easily into new and existing software projects
What’s been done already?
Another thing that Ruby and Python share is a large swath of third party libraries and package/dependency management tools for integrating these libraries into applications. For package and dependency management, Python utilizes Pip and Setuptools while Ruby utilizes RubyGems and Bundler. In addition, both Pip+Setuptools and RubyGems+Bundler help developers to configure their application to utilize a particular set of libraries. These tools even provide functionality for managing versions of the specified libraries. The example below shows how easy it is for developers to install a set of specified packages during the initial setup of the application.
$ bundle install
Fetching gem metadata from http://rubygems.org/...........
Fetching version metadata from http://rubygems.org/...
Fetching dependency metadata from http://rubygems.org/..
Installing rake 10.4.2
Installing Ascii85 1.0.2
Installing andand 1.3.3
Installing memoizer 1.0.1
Installing i18n 0.7.0
Installing json 1.8.2 with native extensions
Installing minitest 5.5.1
Installing thread_safe 0.3.5
Installing builder 3.2.2
Using bundler 1.11.2
Installing rails 4.2.1$ python setup.py develop
running develop
running egg_info
writing dependency_links to dependency_links.txt
writing top-level names to top_level.txt
writing requirements to requires.txt
writing entry points to entry_points.txt
writing PKG-INFO
reading manifest file 'SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'SOURCES.txt'
Searching for MarkupSafe>=0.9.2
Reading https://pypi.python.org/simple/MarkupSafe/
Best match: MarkupSafe 0.23
Downloading https://pypi.python.org/packages/
Processing MarkupSafe-0.23.tar.gz
Writing MarkupSafe-0.23/setup.cfg
Running MarkupSafe-0.23/setup.py -q bdist_egg
Creating MarkupSafe-0.23-py3.5.egg
Extracting MarkupSafe-0.23-py3.5.egg to python/site-packages
Adding MarkupSafe 0.23 to easy-install.pth file
Installed MarkupSafe-0.23-py3.5.egg
What about the frameworks?
At a high level, the Rails and Pyramid frameworks share a lot of common concepts. They both fit into the category of MVC frameworks that focus on convention over configuration. Although each framework follows a MVC-based design, each framework also follows its own logical layout of application code. When looking at a typical Rails application, a majority of the application code is under the “app” directory in the following layout:
On the other hand, a Pyramid application usually has the following layout:
Without getting into a debate about the “MVC” nature of Pyramid, it is important to point out that according to the authors of Pyramid, out of the box, Pyramid is not a full “MVC” framework:
“You Say Pyramid is MVC, but Where’s the Controller?
The Pyramid authors believe that the MVC pattern just doesn’t really fit the web very well. In a Pyramid application, there is a resource tree which represents the site structure, and views which tend to present the data stored in the resource tree and a user-defined “domain model”. However, no facility provided by the framework actually necessarily maps to the concept of a “controller” or “model”. So if you had to give it some acronym, I guess you’d say Pyramid is actually an “RV” framework rather than an “MVC” framework. “MVC”, however, is close enough as a general classification moniker for purposes of comparison with other web frameworks.” –via Pyramid Introduction
The explanation above helps to highlight some of the differences in the directory structure compared to Rails. As the authors mentioned above, at a base level, Pyramid really only contains “resources” (under the templates directory) and “views” (in the views.py file). The concept of models can be added to a Pyramid application with the addition of an ORM layer. Rails contains an ORM layer (activerecord) by default whereas Pyramid does not. If an ORM (in Piaxbility’s case: SQLAlchemy) is added, a models.py or models directory would then be added to the application. Many of the Pyramid applications at Pixability function as API-based web applications because of the micro-services architecture. In other words, these micro-services don’t handle rendering resources or views. Instead, the views function in the same way that a controller would function in Rails. Below is an example directory structure of a pyramid application at Pixability:
What about testing?
One of the major features of the Ruby on Rails framework is a robust testing framework that allows developers to write tests for every aspect of their application. Although not as feature-rich, Pyramid also provides support for testing an application. For more information, check out: http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/testing.html
Where does that leave us?
Overall, the similarities between these two languages and their ecosystems made the hardest parts of this transition very straightforward. My previous experience with Rails allowed me to spend my time focusing on learning the Python language, instead of spending my time figuring out how to set up a development environment. It is also important to mention that this article definitely does not cover all of the differences between the Ruby and Python ecosystems. For more information, please check out the following:
