Here I am again, trying to run multiple Pythons, with multiple libraries, without them tripping over each other. Many hackers have gone down this path and become lost, I expect I will fare no better, but I've stumbled upon a scheme which works for me, whether running Python on a Macintosh, in a Linux server, or even on Windows.
This weekend I explored the Fish Shell (a modern interactive Unix shell). I've been dabbling with it for a while, particularly enjoying its interactive features: command suggestions, the TAB-completion menu, the fact that it Just Works™ out of the box, and understands commands and options by groking their man-pages.
I've wanted to port a few of my bash functions which I've been missing: my ssh-pass to load SSH keys onto the Agent's keyring with passphrase supplied by pass, and an alias to get my 1password passphrase from pass as well. Also some directory navigation shortcuts that I've used since my university days. I figured these would be a good introduction to how fish's scripting works, and I was right
UPDATE 2020-04-16 This is not how you should do it
These instructions and tools are great if you're going to use Python 2 and Virtualenv. But Python 2 is dead, and there are better ways to do this in Python 3. I'm still exploring the best ways, but I am leaning towards using pyenv + pyenv-virtualenv (or python venvs, or maybe pipenv?). Pyenv takes inspiration from rbenv which is how Ruby does this, so if you know Ruby then you'll understand it. When I understand better, I'll write another blog post
A while ago I noted that I should write about my shell functions for creating and managing Python Virtual Environments. Recently I was helping my boss set up some python virtual environments for some different projects, and I couldn't remember how to use virtualenv directly.
I really wanted to just share my wrappers with him, and I found that they weren't quite ready to share because I hadn't finished documenting them.
This post is to remedy that.
Here is the forth part of my blog series expanding on my 4-bit rules of computing.
Previously in Milosophical Me: Mike was reflecting on Comments, both in source code and in social media, and had come to the conclusion that they are to be avoided, that they can be more harmful than helpful, and that source codes (and people) should be allowed to speak for them selves.
There is an exception to Rule 5 (Rule 0 allows for this): doc-comments. In this post I explore what they are, how they differ from regular comments, and how to use them to assist your fellow hackers.