I am the blog of Hal Fire, and I bring you…

… interesting tidbits of release engineering.

Enterprise Software Writers R US

Someone just accused me of writing Enterprise Software!!!!!

Well, the “someone” is Mahmoud Hashemi from PayPal, and I heard him on the Talk Python To Me podcast (episode 54). That whole episode is quite interesting - go listen to it.

Mahmoud makes a good case, presenting nine “hallmarks” of enterprise software (the more that apply, the more “enterprisy” your software is). Most of the work RelEng does easily hits 7 of the points. You can watch Mahmoud define Enterprise Software for free by following the link from his blog entry (link is 2.1 in table of contents). (It’s part of his “Enterprise Software with Python” course offered on O’Reilly’s Safari.) One advantage of watching his presentation is that PayPal’s “Mother of all Diagrams” make ours_ look simple! (Although “blue spaghetti” is probably tastier.)

Do I care about “how enterprisy” my work is? Not at all. But I do like the way Mahmoud explains the landscape and challenges of enterprise software. He makes it clear, in the podcast, how acknowledging the existence of those challenges can inform various technical decisions. Such as choice of language. Or need to consider maintenance. Or – well, just go listen for yourself.

pyenv & virtualenv can get along

In my (apparently) continuing list of tiny hassles with PyEnv, I finally figured out how to “fix” the PyEnv notion of a virtualenv. This may apply only to my setup: my main python version is managed by homebrew.

If you install a new point release of python via homebrew (e.g. 2.7.11 atop 2.7.9), and then run brew cleanup, you’ll find that your virtualenvs created with 2.7.9 may no longer function correctly.

There are actually 2 problems here:
  1. The pyenv virtualenv may be pointing to a (now) non-existent python library
  2. The original python libraries may still be referenced in sys.path

The first was easy to find - for python 2 virtualenvs managed by pyenv, a file .Python is symlinked to the corresponding framework version. The frameworks are only identified by the major & minor versions (e.g. ‘2.7’), but the file system path to the homebrew installed version contains the point release value as well. So, all of those links need to be recreated. E.g.:

cd ~/.pyenv/versions/py2_venv_name
rm .Python && ln -s /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/Python .Python

The second was more confusing. After fixing the first, the virtualenv’s python would load, but would report errors like “ImportError: No module named __future__”. That needs to be fixed with a similar change to the virtualenv’s lib/python2.7/orig-prefix.txt file, which is consumed by lib/python2.7/site.py. It also contains a file path to the framework version of python. So:

cd ~/.pyenv/versions/py2_venv_name/lib/python2.7
new_framework=$(readlink ../../.Python)
echo -n $new_framework >orig-prefix.txt
rm site.pyc
../../bin/python -c 'import __future__' || echo "still broken"

N.B. that the file does not have a final newline character, hence the bash gymnastics above.