benknight Posted November 8, 2016 Share Posted November 8, 2016 Is there a way inside a workflow's source code to determine whether the user has Alfred 2 or 3? My workflow stores information in the OS application cache/storage directories, e.g. ~/Library/Application Support/Alfred 2/Workflow Data/ I want to update my workflow to use the correct directory for the version of Alfred that's being used, but I don't currently see any way of doing that. Link to comment
Andrew Posted November 8, 2016 Share Posted November 8, 2016 Alfred's version, the paths to the data and cache folders and a whole load of other stuff is actually available in scripts as environment variables: https://www.alfredapp.com/help/workflows/script-environment-variables/ You should be using 'alfred_workflow_data' to get the path for the workflow's data folder. Cheers, Andrew Link to comment
benknight Posted November 8, 2016 Author Share Posted November 8, 2016 Andrew, does this mean I can no longer run my workflow code outside of Alfred's shell environment? Or is there some sort of utility available for that now? Link to comment
deanishe Posted November 9, 2016 Share Posted November 9, 2016 It means that you may have to re-factor your code into Alfred-specific and generally-useful parts. Note that if you edit your workflow in Alfred 3, it will no longer be compatible with Alfred 2 (regardless of whether you use any 3-only features or not). Link to comment
benknight Posted November 9, 2016 Author Share Posted November 9, 2016 (edited) Reasonable suggestion. However the library my workflow relies heavily on is this one: https://github.com/phyllisstein/alp which references Alfred's storage and cache paths. For now I think I'll have to see this is as just being a tradeoff. The best solution for right now is probably setting the environment variables manually if I need to test outside of Alfred. In the future why not have Alfred expose some sort of developer utility (i.e. a bash script) that bootstraps all the Alfred environment variables. Thanks. Edited November 9, 2016 by benknight Link to comment
deanishe Posted November 9, 2016 Share Posted November 9, 2016 That won't work, I'm afraid. alp was discontinued quite some time before Alfred added environmental variables. It has the cache and data paths hard-coded into it. You'll either need to fix alp yourself or use a more up-to-date library. That runs fine outside of Alfred, as it falls back to reading info.plist if the environment variables aren't set. Newer versions default to Alfred 3's data/cache paths in that case, however. Link to comment
benknight Posted November 9, 2016 Author Share Posted November 9, 2016 alp works just fine in Alfred 2, and Alfred 3 with this patch applied: https://github.com/phyllisstein/alp/pull/23. It suppose it could easily be updated to fallback to the data in info.plist as well. By the way, when you say "discontinued" do you mean to say alp was at some point an official Python library for Alfred? Link to comment
deanishe Posted November 9, 2016 Share Posted November 9, 2016 (edited) No, I mean that phyllisstein quit working on it years ago. It doesn't even support a few Alfred 2 features, like modifiers. There are no official libraries for Alfred. As far as Python goes, I'm pretty sure my library is the only one that's properly maintained (i.e. kept up to date with Alfred's features). OTOH, Alfred's added a lot of features over the last couple of years (environment variables, the debugger and especially JSON feedback in Alfred 3) that make libraries far less necessary. Edited November 9, 2016 by deanishe Link to comment
benknight Posted November 9, 2016 Author Share Posted November 9, 2016 Great, thanks for the tips. I'll consider switching over to your awesome-looking Python package and dropping alp Link to comment
vitor Posted November 11, 2016 Share Posted November 11, 2016 On 11/9/2016 at 8:19 PM, deanishe said: As far as Python goes, I'm pretty sure my library is the only one that's properly maintained (i.e. kept up to date with Alfred's features). On 11/9/2016 at 10:21 PM, benknight said: I'll consider switching over to your awesome-looking Python package and dropping alp @benknight I’ll add to @deanishe’s point above that he’s also a very active member on these forums, keeping up to date (and suggesting and discussing) with new features as well as helping users daily. I say that to point out he’s likely the library author — of any language — more in touch with the community. If you’re going to trust any library, trust his. Not only will it likely work correctly for your needs, if it doesn’t you can rest assured you have an interested maintainer that will want to fix the bug. deanishe 1 Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now