Jump to content

_sharedresources — A script to mitigate duplication of bundled outside tools


Recommended Posts

How it works


View a version with syntax highlighting.

  • Call it with the arguments for the tools you need (--help will list all valid ones).
  • It checks if the arguments are valid (i.e. if the script supports those tools).
      * If it does not, it fails and explains why.
      * If it does, it continues.
  • For each tool, it checks if we already have it installed (including in /opt/homebrew/bin and /usr/local/bin/).
      * If we do, it checks if it was previously installed by this script or not.
        * If yes, check how long since its last update. If longer than a defined period, update it.
        * If not, leave it alone.
      * If we do not (have the tool installed), download it to ~/Library/Application Support/Alfred 3/Workflow Data/com.vitorgalvao.alfred._sharedresources.
  • A PATH which includes all tools is output. Use it to set the PATH in your Workflow.


Notes


I’m using ~/Library/Application Support/Alfred/Workflow Data/com.vitorgalvao.alfred._sharedresources (technically, {var:alfred_workflow_data}/com.vitorgalvao.alfred._sharedresources) because I do not yet know if this is a good idea or useful to anyone else. I don’t want to presume and clutter your Workflow data directory with something you have no idea where it came from. So for now it includes my bundle ID, making it recognisable. The leading _ should also help to clarify this is not from a Workflow named SharedResources.


I’m sharing the method not only because it might be useful to someone else, but to extend it and gather feedback. I’m starting to use this in my Workflows and everything seems fine. But I’d still like to know if there are no objections to it. To me it sounds like a net win, but I might be missing something.


Reasoning


Bundling dependencies with Workflows makes for a better experience. It ensures users can start using our Workflows without fumbling with configurations or extra downloads. Many would have a hard time doing so. The tradeoff — a slight increase in size for the workflow — is mostly worth it.


For most dependencies, whatever version we bundle at the time will be sufficient. They don’t tend to be updated all the time, and even if they are the version you included shouldn’t break on its own. If you ever need to update it, you do it and release a new version of the Workflow.


There’s one notable exception to this rule: youtube-dl. It’s an incredibly popular and capable tool with constant releases. But if you want to include it in your Workflow you need to include a way to auto-update it1. You need this since what makes youtube-dl break are external factors; there’s no other option.


A few of my Workflows use youtube-dl. Even though it’s not huge (≈1.5MBs), having a bunch of them with the exact same bundled tool, each one updating it at different times, is inelegant. It was from this use-case that _sharedresources was born.

 


1. Unless you want to go through the trouble of constantly releasing new Workflow versions.

 
Edited by vitor
Link to comment
24 minutes ago, deanishe said:

Would terminal-notifier work with that? Seems like a good candidate.

 

I thought you might ask about that and was going to add a note, but forgot.


Yes, it should work and I’m fine with adding it, but won’t use it myself. Reason being terminal-notifier cannot perfectly fake/use an outside icon. The best it can do uses an icon you chose, yes, but it still adds their own. As far as I’m aware this is a technical limitation from macOS, not a design choice, but it still makes it less than ideal.

Link to comment
Just now, deanishe said:

I use a small AppleScript app for notifications.

 

Does it work well? Do you have it online?


I also used one I built specifically for Workflows. I used it before terminal-notifier so Workflows could be completely under the Public Domain. However, at one point I got into some issues of it not working due to lacking codesigning, so I had to abandon it.


Since then, I’ve also wondered why terminal-notifier doesn’t break for the same reason. Yes, it is codesigned, but since I’m changing it’s icon and bundle ID, it should be considered corrupt and not work as well. But since I currently have no VM1, I have no way to test if I can get notificator to work.



1. Had to abandon VMWare Fusion because it was always hanging the whole machine and Veertu has been saying they’ll have support for macOS guests “next month” for over half a year.

Link to comment
1 minute ago, vitor said:

Does it work well? Do you have it online?

 

It's part of Alfred-Workflow. As far as I know, it works fine. At least, nobody's complained in the 18+ months it's been in AW. Perhaps I'm the only one using it…

 

The idea is that you only need to call notify.notify('Your message'), and AW will drop a customised version of the app (changed icon & bundle ID) in the workflow's data directory without the workflow author needing to do anything.

 

Link to comment
12 minutes ago, deanishe said:

At least, nobody's complained in the 18+ months it's been in AW. Perhaps I'm the only one using it…

 

That suggests notificator might still work. That was way in the beginning of my Alfred usage and macOS was still OS X. Something may have changed in macOS or my knowledge to get it to work. But again, still waiting for Veertu (or Anka, or whatever).

 

Stil…

 

16 minutes ago, deanishe said:

will drop a customised version of the app (changed icon & bundle ID) in the workflow's data directory without the workflow author needing to do anything.

 

That still means one copy of each for every Workflow (as would notificator) so it wouldn’t give that much advantage over terminal-notifier. Especially since I have a script to customize it fast.

Link to comment

It means two copies for each workflow, as the compressed version is still in the library. And one copy for workflows that don't use it.

 

It has no advantage over terminal-notifier except workflow authors don't need to do anything to support notifications.

 

I've no idea regarding Sierra. Don't have it.

Link to comment
1 minute ago, deanishe said:

It has no advantage over terminal-notifier except workflow authors don't need to do anything to support notifications.

 

That’s a considerable advantage, I’d say.

 

I was kind of bundling our two solutions (Alfred-Workflow and notificator) in the same argument. Meaning that if I’d always need to bundle something anyway, I’m not sure I want to go through the trouble of trying to retest/revive notificator when my current approach works fine. A part of me thinks I’ll do it.

Link to comment
5 hours ago, vitor said:

Meaning that if I’d always need to bundle something anyway, I’m not sure I want to go through the trouble of trying to retest/revive notificator when my current approach works fine.

 

I don't think I would, either, if it were for my own workflows. But it's for the library. I went with AppleScript, as it doesn't appear to cause issues with Gatekeeper. Or maybe it does, but nobody's told me yet…

 

I still don't much like the idea of bundling the app with the library.

 

BTW, I noticed a typo in your script: mount_pointt

 

Link to comment
12 minutes ago, deanishe said:

I went with AppleScript, as it doesn't appear to cause issues with Gatekeeper. Or maybe it does, but nobody's told me yet…

 

notificator is AppleScript as well. I don’t think the language matters as long as it’s an app. But again, I don’t recall all the details. For all I know, I might’ve misdiagnosed the issue at the time.

 

12 minutes ago, deanishe said:

BTW, I noticed a typo in your script

 

Thank you. Fixed.

Edited by vitor
Link to comment

Went back on a previous decision. In practice, getting all tools at once and getting a PATH from that seems like it might be easier to manage and less weird to call in the Workflow itself (call the tool instead of a variable with its path).


Starting to add it now to Workflows. We’ll see if it’s better or not.

Link to comment
  • 1 year later...
  • 4 weeks later...
1 minute ago, vitor said:

Due to the binary’s name, that one breaks the pattern of getting from Homebrew. I don’t want to add an exception for that one since I don’t use it and as such wouldn’t know if it broke.

 

I expected this, fair enough!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...