Brooke Kuhlmann

Hello, everyone. 👋 This is a bit self-promotional -- apologies -- but I published an article, today, on using Alfred as an API client to your web service which might be of interest to folks. Basically, I can use Alfred as a native client for browsing my web site all through using Alfred Script Filters to make a curl request to my site's API. Makes for really fast browsing. 🎉 As an example, here's a screenshot of the results that come back: Anyway, more details in the article (linked above) but might also be a cool way for you to leverage Alfred -- as a client -- for your own site/service. Enjoy!

Yeah, that sounds great. I also like that you'll support encryption too. Even better!

Definitely enjoying Alfred 5's new user configuration UI. Great work. Would it be possible to add a Password Field that is equivalent to a Text Field but the value in the input is masked? The reason why this would be handy is because this would allow users to supply sensitive information that is hidden from view by default. Great when taking screenshots, having someone enter an API key which you don't want others seeing when demoing your workflow, etc. Here's what I'm thinking that would be nice to have: Then, with the UI, this could be masked: There could even be a little 👁‍🗨 icon to the right of the text field for anyone who wanted to temporarily reveal the contents of the text field. At the moment, the only way to work around this is to manually inform users of your workflow (via the workflow documentation) to update their environment key for a the currently installed workflow with the sensitive information that you don't want to show in the screenshot above. I'd like to reduce the need for this manual step on my users if possible. Thanks!

Hey Andrei. 👋 You shouldn't need to worry about rbenv, only that your environment is loaded properly. This is all documented, here, in the Workflow section of Pennyworth. Feel free to open an issue if you have troubles. I wasn't aware of Alfredo. Thanks for pointing this out to me. As a cursory glance, it doesn't look like it is maintained all that well but I'll dig into it further.

Correct. This goes back to my earlier point in that I've been writing Alfred Workflows for the Ruby community because my tooling tends to augment a fellow developers' workflow. Ah, OK. I didn't read closely enough, thanks. Also, that makes sense that Alfred Powerpack licensing would be an issue for CI builds.

@deanishe Thanks, yeah, I was looking over your project. That's basically how I test Pennyworth. It emits JSON as well and I just test the output which is quite easy and reliable. I don't actually do a full integration test where the Alfred workflow is triggered. I suppose I could do that as well and worth thinking about more. There is one advantage that I don't have is that you can compile and embed your application within the workflow which is neat. I don't have that capability with Ruby due to being a dynamic language.

@deanishe Ha, yeah. On the flip side, I also learned something new because I didn't realize their wasn't more of a space for supporting custom Ruby versions like I've been doing. I always assumed it was the norm. So my shock of finding this out -- 9 years later -- is quite surprising. 😅 ℹ️ By the way, it would take a significant amount of effort to rewrite Pennyworth to support Ruby 2.6.0 or any version of Ruby older than 3.0.0. This was the entire impetus for creating this post/announcement in the first place because the gem had been entirely written to support the new Ruby 3.0.0 syntax. 🎉 @vitor Yeah, definitely for the Ruby engineer who loves working with the latest version of Ruby and wants to leverage those features.

Hmm, yeah, that's a real shame. 😢 I also wasn't aware of the support issues. I've never seen issues on GitHub related to the Pennyworth project so assumed fellow Ruby engineers were humming along without issue. Hmm, yeah, I can't speak to the JavaScript crowd. I just know that I've been writing and supporting Alfred Workflows -- using Ruby -- like this for 9 years now while always using the latest and greatest version of Ruby. Never had an issue or an issue with my team (if that's any small condolence).

Correct, I am limiting my audience and reach. There's no doubt about that but I'm also an engineer and want to programmatically leverage Ruby to power Alfred in ways not possible with using out-of-the-box native Alfred Script Filter support. Pennyworth does not generate a workflow, bundle the Ruby runtime, or subsequent gem (library). The assumption is that you are a Ruby engineer who will install the Pennyworth gem and then install the supporting Alfred Workflow. I take it, from this conversation, that engineer focused Alfred Workflows and sharing of them here in the Alfred forums is a bit...rare or unusual?

Ah, OK, I understand where you are coming from now. I'm targeting fellow engineers only. 😅 Nope, Pennyworth is built using Ruby 3.0.0 syntax and the macOS System Ruby is on Version 2.6.3. Totally not possible to use Pennyworth with the system or Alfred defaults. 🙇🏻 Yeah, that makes a lot more sense based on your earlier feedback. Yep, I definitely understand where you are coming from now. Thanks. I'm afraid I can't comply, though, sadly. 😢 The reason is two-fold: Alfred uses the system Ruby (i.e. Version 2.6.3) which is too old. Several years back I started out writing Ruby within the Alfred Script Filter but there's no way to reliable test Ruby code which leads to maintenance nightmares. It's much easier to encapsulates the functionality within a Ruby gem, package, ship, and then write a simple Alfred Script Filter which messages the gem.

> Why doesn't specifying the full path to the correct Ruby executable work? So you might have multiple versions of Ruby installed at once which will be several versions ahead of the system version (i.e. provided by default in macOS). The macOS Ruby version is generally not preferred or used since every Ruby engineer uses a Ruby Version Manager to deal with this. With a Ruby Version Manager (https://www.alchemists.io/articles/ruby_version_managers), you can easily switch between different versions at will. For example, with a Ruby Version Manager, you might have the following installed: - 2.6.3 - 2.7.2 - 3.0.0 - 3.0.2 ...and out of those versions, 3.0.2 might be the global version you have the Pennyworth gem installed in which you want Alfred to pick up dynamically in the Script Filter. For example, that full path might look like this: $HOME/.cache/frum/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pennyworth-11.1.0/bin ...but let's say a new version of Ruby comes out, like 3.0.3. You'd have to update the path from 3.0.2 to 3.0.3. Same goes if Pennyworth is upgraded in which case you'd have to upgrade from 11.1.0 to 11.1.1, for example. It's much easier to install Ruby 3.0.3 and Pennyworth 11.1.1 -- or any combination of -- without having to adjust the Alfred Script Filter in addition. Alfred, will just pick everything up dynamically via the shell instead which a nice win. > .bashrc is not supposed to be loaded in non-interactive shells, and it's fairly common practice to put something like [ -z "$PS1" ] && return right at the top of .bashrc to make sure it isn't (bash will still try to load .bashrc if it detects it's being run by ssh). > For other people who load a bunch of stuff in their shell, it will ruin workflow performance. Yeah, you have a valid and strong point. I've been using Alfred + Pennyworth this way for years so haven't had any issues logged against this usage yet but I agree, I can do better in this regard. My main goal was to ensure people could use Alfred + Pennyworth with very little scripting necessary within the Script Filter or further maintenance on their part. So ensuring -- or letting anyone dictate -- how their environment should be loaded is key (whether it be Bash, ZSH, Fish, etc). I also don't want to have to figure out which Ruby Version Manger someone is using. I'm using Frum but others could be using RVM, rbenv, chruby, or asdf for example. I will research if there is a better way to do this without using .bashrc. One thing that might help is Alfred could let me select from any of my shells. For example, if `cat /etc/shells`, I get: /bin/bash /bin/csh /bin/dash /bin/ksh /bin/sh /bin/tcsh /bin/zsh /opt/homebrew/bin/bash It'd be really nice to select `/opt/homebrew/bin/bash` within the Alfred Script Filter but Alfred never detects that last line. Anyway, definitely open to any suggestions to make this a smooth experience (beside the .bashrc suggestion you had). 😅

Hey @deanishe. 👋 The short answer is there is no easy way to teach Alfred how to use the correct version of Ruby installed on the system, sadly. So it's critical that one's shell is properly loaded before Alfred runs the Script Filter to pick up the correct version of Ruby AND load the correct version of Pennyworth as well. To illustrate further, here's the main problem with Script Filters: The only way to trick Alfred, so-to-speak, into using the correct version of Ruby is to force Alfred to load your current shell when running the Script Filter. That means, for these two lines of code in a Script Filter: source "$HOME/.bashrc" pennyworth --http_statuses ...the above then ensures, the correct Homebrew installed and managed version of Bash and Ruby is used.

Hello everyone. 👋 I wanted to post about my Pennyworth Ruby gem which might be of interest to folks here: https://www.alchemists.io/projects/pennyworth With the gem installed, I use Ruby to power many of the workflows but this project also has a collection of many non-Ruby powered workflows too. The entire project is devoted to supporting Alfred. Please read the project documentation for more info. Let me know if there are any questions. Thanks and enjoy! 🎉