Portability versus Configuration

I keep finding myself in this somewhat obnoxious situation at work:

I write a python script so that I don’t have to manually process xlsx and/or/to csv. Common changes include things like column removal, record addition, file concatenation, and so on.

I want to make it useable for the whole team, but doing so comes with some tradeoffs:

  1. Buy-in. Notwithstanding that my coworkers aren’t programmers, there’s a very limited set of people who are well versed enough to do manual spreadsheet processing. So using the terminal is pretty much out of the question. Not a big deal – I can wrap a shell script with Automator and export as a native macOS app. I actually kind-of like this method because it’s so simple. But then there’s a tool for each process, and that just feels messy. I’d like this a lot more if I could figure out a way to allow users to select which task to run against which input files.
  2. Dependencies become harder to manage. While my coworkers’ Python binaries are almost certainly stock macOS, the biggest challenge here is actually on the Python side: Some py packages have a pretty clear divide when it comes to support for pre-3. So, you need both 2.7+ and 3, and a package manager (a good idea anyhow) – AND then you’d need to include any all supported binaries in your build. I honestly haven’t bothered doing this yet, it feels too bulky.
  3. While most of these processes are doable in many Shell languages, the syntactical gymnastics required makes it an untenable exercise in taking compatibility too far for the sake of avoiding the configuration spaghetti tangle described above.

I myself only recently bit the bullet to so speak and decided to limit my BASH/ZSH use for simple IO/FS/Built-in operations. More often than not I find myself not sharing my scripts and just taking on the simplified work because it’s just much faster than getting things set up for someone for whom being a technical wizard isn’t nor should be a priority.

Leave a Reply