Jump to content
vitor

_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 /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 3/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

Share this post


Link to post
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.

Share this post


Link to post

I asked mostly because I know you use it a lot. Figured there was a good reason you hadn't included it.

 

I use a small AppleScript app for notifications.

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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

 

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...