Recently, I spent the better part of a weekend installing Linux under Windows and building some command line muscle memory. Not only did this re-kindle some fond memories from my early days of computing, but it also began to set the stage for effective python development.
Bash on Ubuntu on Windows
Recently, Windows 10 gained a beta feature that allows you to install and use the bash shell as if you were working on Linux. As I understand it, the Unix system calls are translated on the fly for execution in the NT kernel. In other words, it’s not a dual boot setup or a virtual machine layer. Rather, it’s a very interesting mix of the typical Windows experience with a tasty smattering of the command line for those who are so inclined.
Windows Subsystem for Linux - Fall Creator’s Update
The recently-released Fall Creator’s Update for Windows 10 included a host of improvements and added functionality. Of personal interest to me, WSL no longer requires developer mode and is no longer considered to be a beta feature. This development, in particular, appealed to me as it seems to indicate that this hybrid workmode is less of a niche target and more of a mainstream use case that Microsoft is serious about supporting and improving. Additionally, being able to install multiple distributions from the Windows App Store indicates a serious level of collaboration with the individual Linux distributions.
Since I started hobby programming in python roughly a year ago, I’ve noticed that most documentation and examples seem to assume that the user is working in macOS or Linux. At times, Windows seems to be a second-class citizen. When documentation for Windows is included, Visual Studio typically figures prominently as an integral component of the build toolchain. I’m curious to see if the sledding gets any easier in an environment where compilers and other dev tools are installed by default.
A second motivator for installing WSL is the fact that it is pretty effectively sandboxed from the important bits of Windows. Both of the machines that I have been hacking on are shared with the rest of my household, and I am careful to keep in mind that any software installs or registry hacks will at least cause some clutter in the \Program Files directory, and at worst could cause serious deterioration or even destruction of an appliance that is critical to our day-to-day adult responsibilities.
Lastly, I was a full-time user of Ubuntu in the Dapper-Edgy-Feisty timeframe, and am curious to see how far the state of the art in Linux has come since then.
One issue that has been an on-going frustration with python is getting autocompletion to work consistently. I was never successful in installing and configuring the plugins necessary for Python auto-completing to work in Atom. Later, I had some success with Visual Studio Code, but found that the hardware requirements were a little steep for our primary desktop PC.
Since reading that Vim and python are a match made in heaven, I took the plunge with vimtutor a few weeks ago and have started to crest the first hill in the learning curve. This past weekend, one of my first victories was the successful integration of jedi-vim and YouCompleteMe. This has definitely made python development much more enjoyable, as I can preview function signatures and module documentation directly in the editor. I have gotten very accustomed to Intellisense and library browsing in the VBA IDE, and am happy that my user experience in python will be very similar from a usability standpoint.
tmux is a terminal multiplexer that allows for an “editor over shell” configuration similar to the default layout in Visual Studio Code. This setup makes it very easy to drop into git and other cli tools while keeping context with the file(s) currently being edited in vim. This was an easy install, and with the help of a basic cheat sheet I am now splitting and spawning multiple terminal windows on a single screen with nary a hint of input from the mouse.
cmake and make
With tmux and auto-complete now up and running, I set my sights on building some software from source cloned from github. This brought back some memories from my initial forays into Linux circa 2003 that involved multiple failed attempts at installing software from source. This time around there were a few hurdles to clear, but eventually the package built successfully and the module imported with no complaints.
Speaking of github…
This weekend also marked some of my first forays into code collaboration
For one, I created a feature branch in a repository that I had cloned
a few weeks earlier.
I made some changes and did some testing to confirm that everything was
working as expected.
Then, I noticed that the upstream master branch had been updated since
the time of my fork.
So, I had to merge my master branch with the new changes from upstream,
then merge my feature branch and push back to my remote fork.
Of course, I didn’t get all of that right the first time through.
After a few newb mistakes, I eventually got to a pretty messy state of affairs.
With some help from Google, I ended up issuing a
as a sort of mini ‘nuke and pave’.
Although it took longer than initially planned, I ended up re-connecting some cli neurons and getting reasonably proficient in bash, git, and vim. These new workflows remind me of the many hours spent in front of a monochrome green terminal connected to an Apple ][e or IBM PC/XT. In some use cases, I actually much prefer the command line to wrangling a mouse through menus, windows, and inconsistent form controls. It definitely feels like I have settled into an environment that will serve me well and fits my personal preferences on computer usage and software development — at least, with python.